[lug] [OT] sha1 algorithm, no salt?

[D. Stimits]

Rob Judd wrote:
>>I'm looking at some NIST web pages on the sha1 one-way hash algorithm,
>>and it seems odd that it looks like it does not use any kind of seed or
>>salt value. Is this correct, that sha1 just takes data, and does not
>>require a sepate seed? Reference:
>>  http://www.itl.nist.gov/fipspubs/fip180-1.htm
>>  http://csrc.nist.gov/publications/fips/fips180-1/fips180-1.pdf
> 
> 
> SHA-1 does not take "salt", nor does MD5.  In fact most unkeyed hash
> algorithms do not use salt.  One reason for this is the intent of the hash
> algorithm.  A hash is intended to accept an arbitrary length input and
> produce a fixed length output, while being collision resistant; i.e. it is
> hard to find two different inputs x and y such that hash(x) = hash(y).  A
> consequence of this is that a decent hash function may be used in a
> password protocol that may itself use salt.  Notice the difference between
> the hash and the protocol, though.  Many algorithms (e.g. RSA) are
> insecure if not used with an appropriate protocol.
> 

This is what the description seems to say, I had to verify it though.

> 
>>Generating a salt/seed seems to be both a way of increasing the size of
>>dictionary that a dictionary attack would require, as well as a weakness
>>in some of the other algorithms used for passwords. Is this really what
>>it looks like to me, no more salt?
> 
> 
> This is somewhat true, but salt really isn't the issue: salt cannot
> protect against a poor password.  The reason for using, say, MD5 instead
> of crypt() (which is just DES) is that it will accept arbitrarily long
> passwords, thus making it easier to come up with a decent password that is
> also not too hard to remember, and making dictionary attacks infeasible.
> As such, putting in extra salt is really not necessary: if the user uses a
> long enough password, then you can think of the first few characters as
> salt without the overhead of storing it.  But if the user is determined to
> use a short password, then it is vulnerable to a dictionary attack, salt
> or no salt.


Yes, it makes sense. What triggers the question is that the glibc 
version of crypt() will use MD5 instead of DES if you supply a salt 
starting with "$1$", but it still seems to use the remaining part as a 
salt. Strangely, I could not find any real reference to salts in rfc's, 
though I've looked most closely at SHA1. My guess is that the only 
reason a salt is available for the MD5 version of crypt() is for some 
weird backwards compatibility, and possibly so that the same password 
would not be obviously the same on multiple systems if they were all 
viewed (they would appear to hash differently unless the salts were also 
the same...a salt would add some difference between machines if the pass 
itself were invariant...perhaps a minor advantage).

D. Stimits, stimits AT attbi.com

> 
> I hope this makes some sort of sense.
> 
> Cheers, Rob
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
>