This might work, although 90% of the steps seem to unnecessarily (and
perilously) complicate the algorithm. What's wrong with starting
with input SALT || PASSWORD and iterating N times, where N is chosen
(but variable) to make brute-force attacks take longer? It seems
like the designers are trying to specify a cryptographic hash
algorithm...where they make black box calls to SHA-256 or SHA-512.
It's much simpler to just let SHA-256 and SHA-512 do the work.
Adding a requirement that the salt be 128 bits (or more) would
improve the security against brute-force attacks more than any of the
other (convoluted) parts of the algorithm. I suppose one could argue
that 8 ASCII characters for the salt is relatively secure today, but
what about in 20 years?
Martin
On Oct 11, 2007, at 11:49 PM, james hughes wrote:
I forgot to add the links...
http://people.redhat.com/drepper/sha-crypt.html
http://people.redhat.com/drepper/SHA-crypt.txt
On Oct 11, 2007, at 10:19 PM, james hughes wrote:
A proposal for a new password hashing based on SHA-256 or SHA-512
has been proposed by RedHat but to my knowledge has not had any
rigorous analysis. The motivation for this is to replace MD-5
based password hashing at banks where MD-5 is on the list of "do
not use" algorithms. I would prefer not to have the discussion
"MD-5 is good enough for this algorithm" since it is not an
argument that the customers requesting these changes are going to
accept.
Jim
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
