Re: Values to use for a salt?

> thanks for correcting my overly broad statement that salt must be secret - 
> there are definitely situations where salt is not secret.  Incidentally, 
> Windows 2000 and later (not sure about NTLMv2 under NT4) use a method other 
> than salt to provide uniqueness and randomization.
> 
> Still, the point remains that salt can provide two functions: increased 
> randomness and uniqueness of a password's hash.  Highly random salt, if 
> used for all password's, only increases the randomness of a password.  It 
> does not solve the uniqueness problem - two people with the same password 
> would still have the same password hash code.  To make the point more 
> relevant, consider authentication for a web application.

Disclaimer: I know nothing about windows hashing in any way.

What you say above makes no sense.  If two people have the same
password, and the hash function used two different salts for
them

	The salt for each user needs to be stored somewhere
	(Specifically, it's stored in the resulting hash
	for unix-style password hashing ala DES, MD5, BSD
	blowfish, etc)

	The resulting hash should be different for these
	two users with the same password.

	This provides 'uniqueness of a passwords hash' as
	stated above.  Or, more accurately, you have more
	potential hashes for the same password.  4096
	for DES for example.


If the resulting hash isn't different, then the salt was
irrelevant, and your hash function sucks.

If the hash function uses the same salt for every user, then

	The system-wide salt needs to be stored somewhere
	(in the registry, etc) and could be secret if you
	want for additional obscurity.

	Two users with the same password will have the
	same hash, but two users on different systems
	(which use different salts) would have different
	hashes.

The first part listed above, 'increased randomness ... of a password's
hash' doesn't make much sense to me.  If you mean the hash will
be more random, then you have a bad hash function.  The whole point
of a good hash algorithm is that the result should be totally
unlike the input, small changes in the input result in widely different
hash results, and the results should be uniformly distributed over
the resulting space (ie you should have no 'clumping' of results.)
So salts have nothing to do with this, since it shouldn't be an
issue if you have a proper hash function.



I haven't read the rest of the email, but there's clearly
some confusion in the original paragraph above.


--
Brian Hatch                  "Fashion is what one
   Systems and                wears oneself.  What
   Security Engineer          is unfashionable is
http://www.ifokr.org/bri/     what other people wear."

Every message PGP signed

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/4mGDidaA3abfMooRAuWVAJ9pDBnd2jofddRdhMe3uA+Orn3RDgCfVQ7S
nqEzDf3LbcT7452LMbr8LXg=
=iP9y
-----END PGP SIGNATURE-----