<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 3, 2014 at 12:10 AM, Kevin W. Wall <span dir="ltr"><<a href="mailto:kevin.w.wall@gmail.com" target="_blank">kevin.w.wall@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I suspct the discussion would be more productive if it were more<br>
tightly focused --- for example, changing the string-to-key function<br>
used by ssh to protect its private key file, versus changing the<br>
string-to-key function for PPP CHAP authentication, etc.  The cost and<br>
the benefits for making this change are quite different.<br></blockquote></div><br><div style="font-family:'courier new',monospace">Sorry to jump in so late here, but I think the problem<br>of securely protecting stored passwords--at least when<br>


used for authentication purposes-goes beyond merely<br>finding a sufficiently secure KDF. Scrypt has been<br>around for awhile, and bcrypt before that. And PBKDF2<br></div><div style="font-family:'courier new',monospace">

has been an RFC since 2000 (see RFC 2898). But if you<br>take a look, you'll see that these are seldom used.<br></div><div style="font-family:'courier new',monospace">I would contend that it is not that security folks<br>


are not aware of their benefits</div></div></div></blockquote><div><br></div><div>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:</div>
<div><br></div><div><a href="http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html">http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html</a><br></div><div><br></div>
<div>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?</div>
<div><br></div><div>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.</div>
</div></div></div>