fscoto
commented
3 years ago Thanks for pointing this out. Due to the way BLAKE2 works, hash_size also influences the output, actually. It's not just a truncation. Similarly, crypto_argon2i_general's extra parameters also influence the output, but that's likely not surprising to anybody..
I'm not entirely convinced that this is entirely necessary and I've deviated from your wording in hopes to be comprehensive, but I don't really have particularly hard feelings about anything.
LoupVaillant
The Argon2i docs don't explicitly state that the output hash value depends on all the inputs, not just the password+salt. Or in other words, that altering the n_blocks or n_iterations parameter changes the hashes produced. This is probably obvious to an expert, and it was obvious to me once I thought it through for a minute :) but it could be easy for a developer to overlook since there is advice about tuning these parameters to the hardware. If the program is ported to faster or slower hardware, it may be tempting to change the blocks/iterations to accomodate, but this would invalidate any existing hashes.
I can imagine scenarios like:
A mobile developer uses Argon2i to password-encrypt files. They notice that the hashing is too slow on a low-end device, so they "cleverly" have their code choose different values at runtime based on the CPU clock speed. Everything works fine in development, and even in production ... until the first end user upgrades to a new and faster phone, migrates their existing data and apps, and finds that they can't open any of their encrypted documents anymore.
Or: Our app hashes passwords on-device to derive hashes used as keys to authenticate to a server. Now we're producing a dedicated IoT device that also connects to that server. Unfortunately the IoT device only has 512KB of RAM and a 300MHz clock, so there's no way it can run Argon2i with the same parameters! If only we'd realized this when we designed our auth system!
I would add a warning something like "Changing the n_blocks or n_iterations alters the resulting hashes, so once you have a system in production, you can no longer alter those parameters without breaking all password validation."