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