On Mon, 29 Oct 2007, [EMAIL PROTECTED] wrote: > So back in the bad old days when hashing was DES encryption of the > zero vector with a fixed key, someone came up with salt as a password > strengthening mechanism. > > I'm not quite sure why it was called salt. > > It perturbed the S-boxes in DES IIRC, but essentially it was a known > bit of text that was an input to the algorithm that varied between > entries, like an IV does with encryption. > > If there isn't already a term for this, I'm going to call this > general concept "individuation", or possibly "uniquification". > > Nowadays with strong hash algorithms, but rainbow tables and > low-entropy passwords as the threat, I'm wondering what the best > practice is.
Use a good existing password hash (e.g. OpenBSD's bcrypt[1]) or some well reviewed KDF (e.g. PKCS #5 PBKDF2[2]). Perhaps I'm not imaginative enough, but I can't think of a use case that is not covered by these algorithms. Given decent salt they will not succumb to reverse (rainbow table) lookup and both include parametised computation complexity to drive up the cost of brute force attacks. -d [1] http://www.openbsd.org/papers/bcrypt-paper.ps [2] http://www.rsa.com/rsalabs/node.asp?id=2127 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]