The libsodium authors are quite fast in replying, and the answer was that this was an intentional design decision: The argon2 paper itself states that a salt size of 16 bytes is going to be sufficient for everything, and an output key length of 256 bits is also a sane value, which can theoretically be truncated if needed. With many things, libsodium forces some well-reasoned defaults into high level abstractions to make it impossible to accidentally make it unsafe by using bad values. In my opinion, this is a good approach to designing a cryptography library. The *important* security parameters, which are CPU and memory cost, are still configurable, even in the high level abstraction, and can be configured by the end user depending on their requirements/hardware constraints. On 08.03.2017 14:05, Simon Levermann wrote: > 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