RE: Values to use for a salt?

Correction:

With apologies, the compression function inputs in both SHA-1 and MD5 are
512 bits or 64 bytes.  That's a big deal, because it means splitting the
password and salt for the purpose of precomputation is almost always going
to be impossible, and when it's not impossible due to very large salt
values, infeasible.

I have to conclude that the order of salt and password doesn't matter,
unless I'm missing something.


-----Original Message-----
From: Kenneth Buchanan 
Sent: Friday, December 19, 2003 3:17 PM
To: 'Brian Hatch'; Scott Cleven-Mulcahy
Cc: Michael.Wojcik@xxxxxxxxxxxxxx; secprog@xxxxxxxxxxxxxxxxx
Subject: RE: Values to use for a salt?



>       SALTpassword    <== precompute hash of SALT, then do all
>                           possible passwords.

Without intending to dispute your good advice, the above statement is only
true if the size of the salt is >= the size of the input to the hash
compression function.

In SHA-1 that's 20 bytes, I believe.  So if you use a 64-bit salt, then the
appending order of password and salt is irrelevant for passwords up to 12
bytes long.

But that's just being picky.  You should still put the salt after the
password, particularly since those 12 password bytes don't go very far if
your password happens to be a Unicode string.  And the MD5 compression
function uses a 16-byte input, leaving you with only 8 bytes of password
space before spilling over into the next hash iteration.

> I still have no idea what you really mean here.

I think he meant 'more random hashes', which isn't really true.  The *only*
purpose of a salt, as has been mentioned repeatedly in this thread, is to
provide resistance to dictionary attacks by making precomputation
infeasible.  For this it must be unpredictable by the attacker.  Once you
get passed this then you are either  misusing salts, or you are calling
something a salt that really isn't (ie. MAC key != Salt, which is a
confusion that appeared to be popping up in other messages).