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
Add pwhash argon2i #261
Add pwhash argon2i #261
Conversation
Codecov Report
@@ Coverage Diff @@
## master #261 +/- ##
==========================================
+ Coverage 99.85% 99.88% +0.02%
==========================================
Files 36 37 +1
Lines 1418 1698 +280
Branches 69 90 +21
==========================================
+ Hits 1416 1696 +280
Misses 1 1
Partials 1 1
Continue to review full report at Codecov.
|
I don't understand what's happening in jenkin's windows environments, since all of the symbols I'm using seem to be correctly exported, at least from a libsodium's include perspective. |
libsodium is precompiled on the windows builder and appears to be out of date. Looks like I need to upgrade it. |
Thank you for letting me know. Those Jenkins errors got me worried! |
Jenkins, retest this please |
1 similar comment
Jenkins, retest this please |
f5f00ff
to
81b678d
Compare
phc-winner-argon2/argon2 hasher built from https://github.com/P-H-C/phc-winner-argon2 sources The python driver used to generate the json data is available as a gihub gist at https://gist.github.com/lmctv/b035a96ca7c867464ab62482dc81555c For raw kdf usage, fix salt length to 16, as required by libsodium's API
both at cffi level and at python nacl.bindings level.
* insert argon2i examples * add some notes about modular crypt() format
81b678d
to
0d2c5fd
Compare
for argon2i and scrypt parameters exposed since version 1.0.12 of libsodium.
and remove now unneeded local definitions.
@reaperhulk is jenkin's
caused by a too old libsodium library as happened on february? |
@reaperhulk I think this is ready for review now (assuming the windows problem stems from outdated libs) |
No doubt. I haven't had a chance to upgrade the windows builders to 1.0.12 yet. |
Jenkins, retest this please |
Eeeh, jenkins is being a pain but hypothetically libsodium is now upgraded. Rebase/push a commit and we can confirm that. |
Looks like there's an issue on 32-bit related to maximum memory limit and I need to do one fix for 64-bit python 2.7 on my end. |
Strange failures:
Must see what happens with crypto_pwhash_argon2i_MEMLIMIT_MAX on a 32bit linux system. |
the 64-bit error should be resolved. I had a missing header. |
Any kind of review would surely help both me, if you find missing or wrong stuff, and the committers in reviewing and eventually approving the PR. |
Thoughts on key derivation API
I found no other major issues in usability. My expertise in reviewing the bindings and implementation are non-existent and IANAC, so proper review is up to others. That being said, thank you for your effort! |
@maqp You are right about the need to at least expose the named opslimit and memlimit constants; will comply as soon as I can. As for the limited API, we have to live within the limits of what libsodium itself exposes; in this case, the simplified argon2i API documented at https://download.libsodium.org/doc/password_hashing/the_argon2i_function.html While preparing this PR, I've even tried to open an issue suggesting to also export the low-level full phc Thank you for your time. |
src/nacl/bindings/crypto_pwhash.py
Outdated
given as input. | ||
|
||
:param outlen: the length of the derived key | ||
:type outlen: output key length |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should say int
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm away from my workstation for a couple of days; will add the needed change in a few days.
@@ -0,0 +1,92 @@ | |||
[ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may have asked this before, but remind me where these test vectors are from?
I posted two distict PRs to keep myself honest with the test vectors; but I think this could as well get in all at once. I've generated the vectors scripting the command line interface from mainline argon2, since the RFC vectors used different sized salts, which are not supported by libsodium; if you think it could be useful, I could add the generator script. |
@reaperhulk I just remembered I've already put the driver script I've used to generate the vectors in #260 online at https://gist.github.com/lmctv/b035a96ca7c867464ab62482dc81555c To use the script, and generate a set of test vectors, you need a executable I'm unsure about what is the right place for the gist script in pynacl sources; any suggestions? |
@reaperhulk what about putting the vector generation driver inside the docs? |
We do that with cryptography, although we don't currently have a place for it in the docs here. If you want to add a new section in the style we use on the other project that would be good. |
Just took a look at the general structure of the vectors sectoin of cryptography docs; it seems at least a crude version for pynacl is within reach of my writing skills... |
for crypto_pwhash_argon2i() binding.
@reaperhulk would you mind taking a look at the present status of #287 ? I think that would be the right place for adding a "how this project is tested" heading and then describe where the test vectors come from, and the instructions/code needed to generate those vectors we didn't find a canonical source for. |
@reaperhulk just a little note on merge strategy: since the single-commit in #260 was not altered in this PR, even if merging separately there should be non need to rebasing #261 after merging #260. |
@reaperhulk P.S. for the separate merge to work, I think #260 must be merged as-is and not rebased on top of current master... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, verified the vectors, looked it over again, and left one comment. It'd also possibly be nice to note that there are some known weaknesses with data-independent memory hard functions that data dependent functions like scrypt (or argon2d) do not suffer from. See: https://www.youtube.com/watch?v=YtfVLzUkwME
Essentially: there is a reasonable argument to be made that argon2i is not actually the PBKDF you should use. It is reasonable to still prefer scrypt.
docs/password_hashing.rst
Outdated
>>> Eves_box = secret.SecretBox(Eves_key) | ||
>>> intercepted = Eves_box.decrypt(encrypted) | ||
Traceback (most recent call last): | ||
... | ||
nacl.exceptions.CryptoError: Decryption failed. Ciphertext failed ... | ||
|
||
|
||
Contrary to the hashed password storage case, where a serialization |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small rephrasing:
Contrary to the hashed password storage case where a serialization format is well-defined, in the raw key derivation case the library user must take care to store (and retrieve) both a reference to the kdf used to derive the secret key and all the derivation parameters. These parameters are needed to later generate the same secret key from the password.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here we go 😮
@reaperhulk thank you very much for your continued help and support. |
As suggested by @reaperhulk, I'm early-posting the argon2i bindings I'm working on, to add the needed testing context to the #260 PR and starting to implement #233.
While I think the implementation is reasonably complete, documentation is completely missing.