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

Re: Argon2 Password Hashing

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.



PS: You can view the progress of the openldap-argon2 module in the
argon2 branch of my OpenLDAP fork on GitHub:

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