3 ms·
Probably whatever the libsodium team recommends. For password hashes, looks like Argon2 https://doc.libsodium.org/password_hashing https://doc.libsodium.org/pa
by ReactiveJelly 5y ago
Probably whatever the libsodium team recommends.
For password hashes, looks like Argon2 https://doc.libsodium.org/password_hashing https://doc.libsodium.org/password_hashing
For generic data, they're still using BLAKE2b as the default, not BLAKE3. Not sure why. Too new? https://doc.libsodium.org/hashing/generic_hashing https://doc.libsodium.org/hashing/generic_hashing
SHA256 and SHA512 alone are not awful, but they're slower than BLAKE3 and vulnerable to length extension.
You can add extra tricks to protect them from length extension, like a length prefix or like doing SHA512/256, but it's better not to add tricks to your crypto.
- omegalulw 5y agoWhat about bcrypt?
- duskwuff 5y agoDifferent tool for a different job. bcrypt is a password hash. It's optimized to defend against brute-force attacks on a short secret string -- which means it's slow (tens to hundreds of milliseconds), and it doesn't support inputs longer than 72 bytes at all. SHA256 and the BLAKE family are designed for hashing larger bodies of data. They're fast (~5 CPU cycles per byte) and can handle an arbitrarily long input.
- shp0ngle 5y agopassword hash is not a general hash. general hashes are to be used in other crypto constructions. Or, if you really need just a quick hash (but really think if you really need it.) Password hashes are for passwords.
- charcircuit 5y ago>but they're slower than BLAKE3 It's important to know that this currently isn't true for small inputs for SHA256 when using a cpu with dedicated instructions for it.
- trinovantes 5y ago> vulnerable to length extension I think this is only relevant if you're using a hash as a MAC, in which case you should be using HMAC-SHA256 instead which is not vulnerable to length extension attacks