Password hashing

Martin James Cochran Martin.Cochran at Colorado.EDU
Fri Oct 12 14:02:29 EDT 2007

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?


On Oct 11, 2007, at 11:49 PM, james hughes wrote:

> I forgot to add the links...
> 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 majordomo at

More information about the cryptography mailing list