Just combining several of my thoughts into a single email.
On the Red Hat proposal:
Why does every undereducated person believe that complexity==security? It is
far better to rely on little things called "proofs." There are several
proofs out there with significant impact on this. In particular the really
nice HMAC proof. The absurd complexity makes it highly likely that there is
at least some shortcut in it that hasn't been seen yet.
On SALT || PASSWORD:
In doing that you are assuming collision resistence, and no shortcuts in
computation. It is better than the RedHat proposal, but not optimal.
On NetBSD HMAC-SHA1:
There is a shortcut in the design as listed, using the non-changing password
as the key allows for the optimization that a single HMAC can be keyed, then
copied and reused with each seed. this shortcut actually speeds attack by a
factor of 3. The fix is to use the salt as the HMAC key, this assumes much
less of the hash function.
Also appears to suffer from the same precomputation flaw, possibly more I
haven't looked at it too closely for this purpose.
On USERID || SALT || PASSWORD:
Close, anything that is fixed (USERID and PASSWORD) should be put at the
end, so the there is round to round variation before it, preventing
precomputation. It also assumes the same collision resistence and no
The better solution, with aspects borrowed from the others:
IV = Salt
IV[i] = HMAC(key=IV[i-1], data=USERID||PASSWORD)
Of course nonambiguous formatting for USERID||PASSWORD is necessary to avoid
any shortcuts or precomputations, but any nonambiguous method is sufficient,
including a fixed length USERID.
By using an HMAC instead of just a hash function allows it to make use of
most of the HMAC proof, reducing the assumptions on the underlying hash to
the effective minimum. By ordering everything to place the SALT and later
prior result as the HMAC key this prevents any precomputation under the
assumption that there is no method of computing the hash shorter than 3 hash
compression iterations, a quite small window of opportunity, and any result
will likely benefit the rightful computation of the PasswordHash resulting
in a simple increase in the value of k.
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]