You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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
The text was updated successfully, but these errors were encountered: