Which crate should I use for Argon2?


I’m writing a password manager that will be using the Argon2 function. At the moment there are 3 crates that provide it: argon2rs, rust-argon2 and argonautica.

argon2rs is by far the most popular, is written in pure Rust and uses SIMD, but hasn’t been updated in 3 years and does not implement Argon2id variant.

argonautica is the most idiomatic and well documented. It was updated recently, implements Argon2id, uses SIMD and is generally speaking pretty awesome, but wraps around the reference implementation in C, rather than provide a pure Rust implementation. Author claims to be planning to include a Rust implementation at some point, but considering the fairly slow development I’m unsure if that will ever be the case.

rust-argon2 is written in pure Rust, implements Argon2id and was recently updated, but it claims to be unoptimized and does not use SIMD.

I’m leaning towards argonautica since I will likely need to use non-pure Rust for GUI anyway, but I would like to hear opinions of more experienced programmers.

1 Like


For password hashing function, I’d choose simply one that has the fastest implementation. Anything less than fastest gives your adversary an advantage.



Quite literally going through the exact same decision and conclusions right now. argonautica looked like the best approach, but it’s object oriented design is really going against the grain as I aim for a more functional one. I think a functional approach would be nicer here.



Would you be so kind to explain to those of us with less understanding of the intricacies of crypto why that is? Thanks in advance.



Hashed passwords can be broken with dictionary attacks, i.e. by hashing billions of different passwords, and looking for a matching hash. The way to stop such attacks is to make the hashing algorithm so slow that brute-forcing becomes impractical, i.e. it’d take too long time or cost too much to compute so many hashes.

So you should pick and configure the hashing algorithm to be as slow as you can tolerate. But if your implementation is inefficient, you’ll be burning your CPU on the inefficiency, but not on the essence of the algorithm. Someone else could pick a more efficient implementation for cracking the hash, and won’t be slowed by your inefficiency.

Let’s say you accept a 100ms delay for log in, and burn 100ms of your CPU time on the hashing. If the attacker can find an implementation that is 50% faster, then they can do the same in just 50ms. If you’ve used the faster implementation you could either also have a faster login, or you could double the hash strength (so your attacker would have to spend the same 100ms of CPU time as you).