[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Argon2 Password Hashing

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