[148890] in cryptography@c2.net mail archive
Re: [Cryptography] The problem is not just merely a secure KDF (was
daemon@ATHENA.MIT.EDU (Bill Cox)
Fri Jan 3 10:59:26 2014
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CAOPE6PjBvQKHV4ibim-PGj68dj5MochZ5+4eapFB-quqp-+FTQ@mail.gmail.com>
Date: Fri, 3 Jan 2014 02:29:18 -0500
From: Bill Cox <waywardgeek@gmail.com>
To: Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============8577042525349792875==
Content-Type: multipart/alternative; boundary=047d7b414f403ad61a04ef0bded7
--047d7b414f403ad61a04ef0bded7
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Jan 3, 2014 at 12:10 AM, Kevin W. Wall <kevin.w.wall@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.
--047d7b414f403ad61a04ef0bded7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jan 3, 2014 at 12:10 AM, Kevin W. Wall <span dir=3D"ltr"><<a href=3D=
"mailto:kevin.w.wall@gmail.com" target=3D"_blank">kevin.w.wall@gmail.com</a=
>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-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. =A0The cost and<br=
>
the benefits for making this change are quite different.<br></blockquote></=
div><br><div style=3D"font-family:'courier new',monospace">Sorry to=
jump in so late here, but I think the problem<br>of securely protecting st=
ored passwords--at least when<br>
used for authentication purposes-goes beyond merely<br>finding a sufficient=
ly secure KDF. Scrypt has been<br>around for awhile, and bcrypt before that=
. And PBKDF2<br></div><div style=3D"font-family:'courier new',monos=
pace">
has been an RFC since 2000 (see RFC 2898). But if you<br>take a look, you&#=
39;ll see that these are seldom used.<br></div><div style=3D"font-family:&#=
39;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></di=
v><div>I agree it is beneficial to talk about specific cases, as Kevin sugg=
ests. =A0If the OpenSSL authors are aware of the benefits of the newer KDFs=
, why don't they use them? =A0My private ssh key by default, which by f=
ar is the most important case, is protected by a decent salt and ONE round =
of MD5. =A0Off line, and attacker can throw hardware acceleration at for da=
ys on end to crack my password. =A0Through an obscure option, you can switc=
h to 2048 rounds of SHA-1, and that's the best they offer. =A0There'=
;s a great article here:</div>
<div><br></div><div><a href=3D"http://martin.kleppmann.com/2013/05/24/impro=
ving-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. =A0What=
ever happened to 1 second of computation? =A0Didn'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 ob=
scure options I can do better than one round of MD5, but I have to wonder w=
ho could feel good about maintaining that code with such an antiquated defa=
ult. =A0There are plenty of C programmers still around to fix this. =A0I vo=
lunteer if anyone would like me to provide a patch.</div>
</div></div></div>
--047d7b414f403ad61a04ef0bded7--
--===============8577042525349792875==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============8577042525349792875==--
