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: >> >> 1) 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) >> >> 2) 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? >> >> 3) 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 >> >
Attachment:
signature.asc
Description: OpenPGP digital signature