Paul Vixie wrote:

>>I also have a question about the salt field in the original spec. I still
>>am not sure it is useful. A determined attacker will just take the salt
>>value anyway and use that. Why not just have the hash be the FQDN? For
>>example: Hash(www.example.com).example.com.

>
> that looks really cool, but it doesn't change the danger. home pee cees now
> have 4GHz processors, and it's still doubling every once in a while. apple's
> "altivec" may be the first mass production example of what's about to be a
> very popular kind of technology -- maybe a million vector processors running
> insecure operating systems on 24x7 DSL lines is the right threat model here.


A solution to this is to make the iterations the log2 of the number of
hash rounds, rather than a counter. This better matches the (so far)
exponential increase in CPU speed.

This approach is used by the OpenBSD blowfish password hash function:

http://www.openbsd.org/papers/bcrypt-paper.ps

-d

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: