On Tue, Mar 18, 2008 at 08:27:08AM +0100, Frank Ellermann wrote:
Chris Newman wrote:
> I am not convinced the security value of PBKDF-2
> offsets the additional complexity it adds.
Without asking Google or similar tricks, I have
not the faintest idea what "PBDKDF-2" is. Is it
worse than "APR1" ? That is where I'd draw the
line, scripts taking a minute to shuffle 128 bits
on low end platforms are a PITA.
If you're an implementor then reading the relevant spec (RFC2898, "PKCS
# 5: Password-Based Cryptography Specification Version 2.0", section 5.2
-- slightly over one page of text), IMO, is really in order before
claiming that it's too complex.
> It may be not a lot of complexity, but every
> bit matters.
I'm more interested in nanoseconds than in bits,
but I guess that means we agree.
Oh stop it :), read the spec, notice that PBKDF2 is not much more
complex than Chris' Hi(), and go from there. Both, Chris' Hi() and
PBKDF2 have an iteration count, so the speed of execution is intended to
be variable.
> Everyone's code toolkit includes MD5, but use
> of SHA1 is quite rare in applications at the
> moment. Switching away from MD5 will create a
> deployment barrier.
+1 I don't think SHA-1 is still rare, but it is
a known dead end, and using MD5 as least common
denominator makes sense. Very unfair comparison,
MD5 : SHA-1 : xxx ~ ftp : gopher : http
MD5 is much more a dead end than SHA-1.