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.

On PDKDF2:
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 shortcut.


The better solution, with aspects borrowed from the others:
IV[0] = Salt
IV[i] = HMAC(key=IV[i-1], data=USERID||PASSWORD)
PasswordHash=IV[k]

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. Joe
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to