samuel-lucas6 / Cryptography-Guidelines

Guidance on implementing cryptography as a developer.
https://samuellucas.com/Cryptography-Guidelines/
Other
419 stars 15 forks source link

Salt size #8

Open hakavlad opened 1 day ago

hakavlad commented 1 day ago

Always use a random 128-bit or 256-bit salt

The typical salt size is 128 bits, but 256-bit is also fine for further reassurance that the salt won’t repeat.

generate 256-bit random values for IDs, salts, etc: this reduces the chances of a collision into the realm of not having anything to worry about. By contrast, random 128-bit values will collide after 2^64 due to the birthday paradox.

I just want to express my humble disagreement. 128 bits is a lot, even taking into account the birthday paradox. Salt is not the kind of thing that gets bruteforced out on a quantum computer. Making salt larger than 128 bits is just as pointless as making symmetric keys larger than 256 bits. I agree with the creators of primitives who limit the salt size to 128 bits.

Just a reminder that

2^64 = 1.8e19 // 18 quintillions
samuel-lucas6 commented 1 day ago

I agree that a 256-bit random salt is unnecessary. That was primarily motivated by Latacora and libsodium's scrypt implementation. However, a 256-bit salt makes sense for deterministic salts where you hash something.

There's nothing wrong with a 128-bit salt as that's the standard and NIST recommendation, and there's nothing wrong with a 256-bit pepper as that's a standard key size.

I don't think any of the RFCs actually restrict the salt length besides if there's length encoding. It can even be empty.