phc-winner-argon2

> Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. https://github.com/P-H-C/phc-winner-argon2

Gate keeping is a double edged, and somewhat blunt, sword. First, some Maverick is going to ignore what everyone says and implement crypto for serious applications. Like yours truly. Second, I've seen it go a bit too far when I implemented Argon2i: there was a discrepancy between the specs and the reference implementations, and the authors haven't corrected the specs. I figured this was because not enough independent implementers bugged them about that. (Now, 3 years later, the specs still aren't fixed, so maybe the authors are really really busy. At least but the issue is still open: https://github.com/P-H-C/phc-winner-argon2/issues/183 )

> are they slow because they are computationally intensive... In general, no. Most "slow" hashing schemes are designed to be memory-hard and highly serial (more threads = more contention, not throughput). Some of the earlier approaches just try to maximize computational requirements, but modern research acknowledges the march of computing power makes that an inherently poor choice for long term sensitive data. Argon2 is just one of the more advanced versions of a memory-hard scheme, building on prior research. I could try to give a poor explanation, but instead I'll link you the spec which is very readable: https://github.com/P-H-C/phc-winner-argon2/blob/master/argon...

You can always make a fast hashing algorithm into a slow-enough password hashing algorithm by repeating it multiple times (as with PBKDF2) or better yet using a construction that also uses a minimum amount of memory, not just computational time. For most cryptographic applications (signing data in transit, signing data at rest, computing things like Merkle trees for applications like git and dm-verity), you want a hash that is fast to compute. It's basically only password hashing and cryptocurrency mining that needs to be slow. BLAKE3's readme says: (https://github.com/BLAKE3-team/BLAKE3) NOTE: BLAKE3 is not a password hashing algorithm, because it's designed to be fast, whereas password hashing should not be fast. If you hash passwords to store the hashes or if you derive keys from passwords, we recommend Argon2. Argon2 (https://github.c