Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/crypto/argon2: docs on thread parameter might make users inadvertently create non-portable hashes #42605

Open
m90 opened this issue Nov 14, 2020 · 6 comments
Labels
Documentation help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@m90
Copy link

m90 commented Nov 14, 2020

Both IDKey and Key from golang.org/x/crypto/argon2 take a threads parameter which is documented as following:

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)?

@gopherbot gopherbot added this to the Unreleased milestone Nov 14, 2020
@m90 m90 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
@networkimprov
Copy link

cc @FiloSottile @katiehockman

@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 30, 2020
@FiloSottile
Copy link
Contributor

Yeah, the docs could be better, happy to take a CL. We could go as far as saying "This is commonly left at 1."

@FiloSottile FiloSottile added help wanted NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Dec 1, 2020
@m90
Copy link
Author

m90 commented Dec 1, 2020

Cool, I can see what I can come up with in the next few days and will submit a CL over at the other repo.

@simnalamburt
Copy link

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:

$argon2i$v=19$m=65536,t=2,p=4$c29tZXNhbHQ$RdescudvJCsgt3ub+b+dWRWJTmaaJObG
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     Stored Parameters        Stored Salt            Actual hash

So consider adding a new function which returns encoded hash and verify() function just like the reference implementation.

Reference

@FiloSottile
Copy link
Contributor

@simnalamburt that's #16971, and you're right it will probably help with this confusion, too.

@gopherbot
Copy link

Change https://go.dev/cl/429775 mentions this issue: argon2: amend parameter documentation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants