Yes, I've been using the *str_ and *str_verify versions. I have also successfully verified hashes generated with the PHC default CLI with the libsodium implementation - the salt length and output length parameters are only hidden from the *str_ versions, not from the non-formatted version of the function in the library.
I've opened an issue at https://github.com/jedisct1/libsodium/issues/509 about this, so we'll see what the outcome of this is.
Cheers,
Simon
PS: You can view the progress of the openldap-argon2 module in the argon2 branch of my OpenLDAP fork on GitHub: https://github.com/sonOfRa/openldap/tree/argon2
On 08.03.2017 01:10, Lorenzo M. Catucci wrote:
While I'm unsure I like very much libsodium's attitude regarding constructs' parameters to hide, I'm really happy with crypto_pwhash_str and crypto_pwhash_str_verify being exposed as the "natural" way to do password hash storage and verification, and I'd suggest directly using that serializer in libsodium's case, since it seems the verifier is able to correctly check the passwords generated from PHC default cli, even if some of the parameters used on the PHC side are at values "forbidden" by libsodium's implementation.
Thank you, yours
lorenzo
On 07/03/2017 17:23, Simon Levermann wrote:
Hello,
as discussed in https://www.openldap.org/its/index.cgi/Incoming?id=8575;selectid=8575, I'm currently working on making my argon2 password hashing module also work with libsodium instead of just the argon2 reference implementation. In the progress, a few questions came up:
- Libsodium doesn't expose all of the same parameters to argon2 that
the original implementation exposes. In Libsodium, we can only configure the memory and CPU cost, while argon2 also allows configuring the salt length (fixed 16bytes in libsodium), the hash length (fixed 32bytes in libsodium), and the parallelism (fixed 1 thread in libsodium). So the question is: Do we want to expose these when using the argon2 backend, or do we not want to expose them at all, offering a more unified "API"? Personally, I think these parameters are sane and don't really need to be configurable (as opposed to the work factors, which SHOULD be configurable)
- Libsodium exposes an API for random-number-generation. Should I use
this API for generating the salt when using argon2, or should I always use the openldap-builtin lutil_entropy?
- Regarding configurability: Is there a guide available that shows how
to add configuration parameters to a module? In my current configuration, the memory and CPU cost factors are hardcoded into the module, but making these configurable for users is desirable, since they can potentially raise security based on the amount of Users vs amount of processing power they have.
Best regards, Simon Levermann