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

[Rob Judd]

> 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.

> 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.

I hope this makes some sort of sense.

Cheers, Rob