You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The number of threads can be adjusted to the numbers of available CPUs.
While it's obviously wrong in hindsight, this sentence lead me to pass the (dynamic) value of runtime.NumCPU() as the value for threads when hashing passwords, which means the hashes Argon2 would create are different (i.e. stop matching) on hosts with different numbers of CPUs.
Would it make sense to extend the comments here to point out that threads is not purely performance related, but also has an effect on the hash output (e.g. by stating it needs to be a fixed value and you can use the number of CPUs as a guideline)?
The text was updated successfully, but these errors were encountered:
changed the title
x/crypto/argon2: docs on thread parameter might make users inadvertently create host-bound hashes
x/crypto/argon2: docs on thread parameter might make users inadvertently create non-portable hashes
Nov 14, 2020
There's nothing wrong with using runtime.NumCPU() as P parameter. Users just need to store the P parameter somewhere and recover it before they verify it, just like the any other parameters and salt. Most implementations (including the reference implementation) provides "encoded hash" format to easily store these parameters preventing this kind of human error, while this package does not.
Example of encoded hash:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Stored Parameters Stored Salt Actual hash
So consider adding a new function which returns encoded hash and verify() function just like the reference implementation.