[Cryptography] The problem is not just merely a secure KDF (was "Serious paranoia...")

[Bill Cox]

On Fri, Jan 3, 2014 at 12:10 AM, Kevin W. Wall <kevin.w.wall at gmail.com>wrote:

> I suspct the discussion would be more productive if it were more
>> tightly focused --- for example, changing the string-to-key function
>> used by ssh to protect its private key file, versus changing the
>> string-to-key function for PPP CHAP authentication, etc.  The cost and
>> the benefits for making this change are quite different.
>>
>
> Sorry to jump in so late here, but I think the problem
> of securely protecting stored passwords--at least when
> used for authentication purposes-goes beyond merely
> finding a sufficiently secure KDF. Scrypt has been
> around for awhile, and bcrypt before that. And PBKDF2
> has been an RFC since 2000 (see RFC 2898). But if you
> take a look, you'll see that these are seldom used.
> I would contend that it is not that security folks
> are not aware of their benefits
>

I agree it is beneficial to talk about specific cases, as Kevin suggests.
 If the OpenSSL authors are aware of the benefits of the newer KDFs, why
don't they use them?  My private ssh key by default, which by far is the
most important case, is protected by a decent salt and ONE round of MD5.
 Off line, and attacker can throw hardware acceleration at for days on end
to crack my password.  Through an obscure option, you can switch to 2048
rounds of SHA-1, and that's the best they offer.  There's a great article
here:

http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html

No options for bcrypt or scrypt exist, and you can't even increase to 4096
rounds, which on my machine is about 2.5ms of computation.  Whatever
happened to 1 second of computation?  Didn't we figure out that was a good
idea in the 70's?

Maybe the article above is wrong, and with even more obscure options I can
do better than one round of MD5, but I have to wonder who could feel good
about maintaining that code with such an antiquated default.  There are
plenty of C programmers still around to fix this.  I volunteer if anyone
would like me to provide a patch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140103/a11ced68/attachment.html>