PHK's MD5 might not be slow enough anymore

[Chuck Swiger]

Hi--

On Jan 28, 2010, at 1:56 PM, Garance A Drosihn wrote:
>> On 2010/01/28 12:18, Chris Palmer wrote:
>>> For backwards compatibility, which do people prefer: Creating a new $N$
>>> prefix every time we re-tune the algorithm, or using a new notation to say
>>> how many times this password was hashed? For example: $1.1000$, $1.100000$,
>>> et c.?
>> 
>> I'd vote for $1.nnnn$, as a good side effect it would be tunable by the
>> administrators who want to fine tune the round number as need.
> 
> Might want to make it something like $1.nnn.bbb$, so the admin can specify
> the number of bits as well as the number of rounds.  And then pick some
> algorithm where those two values make sense.   :-)

As Antoine points out in the link mentioned:

> The integration into existing systems is easy if those systems already
> support the MD5-based solution.  Ever since the introduction of the
> MD5-based method an extended password format is in used:
> 
>    $<ID>$<SALT>$<PWD>
>> 
> 
[ ... ]
> For the SHA-based methods the SALT string can be a simple string of
> which up to 16 characters are used.  The MD5-based implementation used
> up to eight characters..  It was decided to allow one extension which
> follows an invention Sun implemented in their pluggable crypt
> implementation.  If the SALT strings starts with
> 
>    rounds=<N>$
> 
> where N is an unsigned decimal number the numeric value of N is used
> to modify the algorithm used.  As will be explained later, the
> SHA-based algorithm contains a loop which can be run an arbitrary
> number of times.  The more rounds are performed the higher the CPU
> requirements are.  This is a safety mechanism which might help
> countering brute-force attacks in the face of increasing computing
> power.
> 
> The default number of rounds for both algorithms is 5000.  To ensure
> minimal security and stability on the other hand minimum and maximum
> values for N are enforced:
> 
>    minimum for N = 1,000
>    maximum for N = 999,999,999
> 
> Any selection of N below the minimum will cause the use of 1,000
> rounds and a value of 1 billion and higher will cause 999,999,999
> rounds to be used.  In these cases the output string produced by the
> crypt function will not have the same salt as the input salt string
> since the correct, limited rounds value is used in the output.

This seems to address the suggestion being made by Chris (and +1'ed by others) in a fashion that is compatible with other implementations....

Regards,
-- 
-Chuck