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
Re 2: Libsodium actually generates its own salt automatically and doesn't require the API user to generate one. So this question has answered itself.
On 07.03.2017 17:23, Simon Levermann wrote
- 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?
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
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:
- 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
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:
- 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
-
Lorenzo M. Catucci -
Simon Levermann