Ring: Feature request: Argon2

[DemiMarie]

Argon2 is the winner of the Password Hashing Competition, and is designed to be memory-hard. As I understand it, Argon2 can also be used directly as a password-based KDF.

Argon2 comes in two forms: Argon2d and Argon2i-B. Older forms of Argon2i are less secure. Argon2d is subject to side-channel attacks due to data-dependent memory accesses, but is not vulnerable to the attacks in Towards Practical Attacks on Argon2i and Balloon Hashing. As I understand it, Argon2d and Argon2i-B are still the best of the known password hashing functions.

I am not going to suggest which form of Argon2 to use. This trade-off will need to be made by experienced cryptographers, not by amateurs such as myself.

Both forms of Argon2 use Blake2b as a subroutine, so one might as well expose the Blake2b implementation used.

[briansmith]

It seems like a good idea to work with @Bryant on his https://github.com/bryant/argon2rs and/or his cargon crate.

[briansmith]

Thinking about this more, I think the next steps are:

1. Try to improve the argon2rs crate, e.g. so that it builds automatically on all platforms without having to manually download the PHC reference implementation.
2. Improve the argon2rs crate so that it works in #![no_std] mode, if possible.
3. Improve the argon2rs crate's API. Maybe @Bryant might consider a more _ring_-like API to be an improvement, and/or maybe the _ring_ API patterns need to improved.
4. Review and add additional tests for the argon2rs crate as necessary.
5. Reference the argon2rs crate from the _ring_ README and/or the _ring_ rustdoc.

In particular, I think if @Bryant is open to such improvements then there's not much benefit to duplicating his work in _ring_. It would be cool if argon2rs and _ring_ could somehow share the common logic like the constant-time comparison, but that looks like the only common functionality.

[bryant]

1. The reference impl is only used during benchmarks. cargo build works just fine otherwise; cf. https://github.com/bryant/argon2rs#installation .
2. What would be the requirements of no_std?
3. Haven't yet looked at ring's API, but I think it would be a straightforward exercise of argon2rs::Argon2.
4. What additional tests do you have in mind?

[briansmith]

The reference impl is only used during benchmarks. cargo build works just fine otherwise; cf. https://github.com/bryant/argon2rs#installation .

cargo test fails for me (on Windows 10 x64): c1: fatal error C1083: Cannot open source file: 'phc-winner-argon2\src\argon2.c': No such file or directory.

It would be nice to have cargo test run correctly on all platforms.

What would be the requirements of no_std?

Basically, don't use anything in std::* but only stuff in core::*.

Haven't yet looked at ring's API, but I think it would be a straightforward exercise of argon2rs::Argon2

I mean, it would be good to look at the argon2rs API and the _ring_ API, e.g. _ring_'s PBKDF API, and see if we can try to make them similar by taking the best ideas from both, so that people who want to use _ring_ in the same problem as argon2rs can do so.

What additional tests do you have in mind?

It would be up to whoever reviews the argon2rs code to suggest new tests.

Maybe I didn't make my point clear, but what I'm saying, basically, is that it would be better to improve argon2rs (to whatever extent it needs to be improved), rather than duplicating its functionality in _ring_.

[burdges]

In the long run, it's worth keeping an eye on metapackages as a way to organize stuff like this.

[Evrey]

As core::* doesn't have any kind of threading, a #![no_std] version of argon2rs might have to panic! for lanes != 1. An other work around would be to allow more lanes, but calculating them sequentially. I'd rather take the panic! approach, as #![no_std] code would otherwise have to take much, much longer to calculate secure hashes than threaded code.

Talking about parameters... @bryant might want to increase argon2::defaults::PASSES to something bigger than 10. Here's why:

However, Joël Alwen and Jeremiah Blocki improved the attack and showed that in order for the attack to fail, Argon2i 1.3 needs more than 10 passes over memory.

src - 2016.10.04

[bryant]

cargo test fails for me (on Windows 10 x64): c1: fatal error C1083: Cannot open source file: phc-winner-argon2\src\argon2.c': No such file or directory.

the cargon dependency and ref impl tests have been isolated to --feature bench_ref.

for the rest, @briansmith and @Evrey, please open an issue or pull request to bryant/argon2rs.

[DemiMarie]

Is it likely that the attack can be extended to more than 10 passes?

On Oct 4, 2016 5:24 AM, "Evrey" [email protected] wrote:

As core::* doesn't have any kind of threading, a #![no_std] version of
argon2rs might have to panic! for lanes != 1. An other work around would
be to allow more lanes, but calculating them sequentially. I'd rather
take the panic! approach, as #![no_std] code would otherwise have to take
much, much longer to calculate secure hashes than threaded code.

Talking about parameters... @bryant https://github.com/bryant might
want to increase argon2::defaults::PASSES to something bigger than 10.
Here's why:

However, Joël Alwen and Jeremiah Blocki improved the attack and showed
that in order for the attack to fail, Argon2i 1.3 needs more than 10 passes
over memory.

src - 2016.10.04 https://en.wikipedia.org/wiki/Argon2

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/briansmith/ring/issues/308#issuecomment-251338573,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGGWB0jxMYg93n6gIdcY9PbUDnwP2tWyks5qwhtAgaJpZM4KMHIo
.

[briansmith]

Closing this because I'd rather work together with other crates doing Argon2, at least for the time being. If new requirements come up then we'll reconsider.