[147507] in cryptography@c2.net mail archive
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was:
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Sat Oct 5 10:40:20 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <524D3639.8080900@iang.org>
Date: Fri, 4 Oct 2013 10:10:48 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: ianG <iang@iang.org>
Cc: John Kelsey <crypto.jmk@gmail.com>,
"cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============6529117455737057190==
Content-Type: multipart/alternative; boundary=089e0160b99886900304e7eade94
--089e0160b99886900304e7eade94
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Oct 3, 2013 at 5:17 AM, ianG <iang@iang.org> wrote:
> On 2/10/13 17:46 PM, John Kelsey wrote:
>
>> Has anyone tried to systematically look at what has led to previous
>> crypto failures?
>>
>
> This has been a favourite topic of mine, ever since I discovered that the
> entire foundation of SSL was built on theory, never confirmed in practice.
> But my views are informal, never published nor systematic. Here's a
> history I started for risk management of CAs, informally:
>
I don't understand what you mean there. The actual history of SSL was that
SSL 1.0 was so bad that Alan Schiffman and myself broke it in ten minutes
when Marc Andressen presented it at the MIT meeting.
SSL 2.0 was a little better but none of the people who worked on it had any
formal background in security. During the design process Netscape finally
got a clue and hired some real security specialists but one of Andresen's
hiring criteria was not to hire anyone from CERN who might suggest that the
Web had been invented by Tim Berners-Lee rather than himself so it took
them a lot longer than it needed to.
During that time I told them about their random number generator design
being barfed and they told me they would fix it but they didn't.
SSL 3.0 was designed by Paul Kocher as we all know and he did a pretty good
job. But they only gave him two weeks to work on it.
I don't think Paul's design was very theoretical and Netscape didn't give
him anywhere near enough time to do a full formal analysis of the protocol,
even were that possible with the tools available at the time.
It is far better to select a target such as 128 bit security, and then
> design each component to meet this target. If you want "overdesign" then
> up the target to 160 bits, etc. And make all the components achieve this.
>
I don't like that approach to hash function design.
Yes, I know that the strength of a 256 bit hash against a birthday attack
is 2^128 but that is irrelevant to me as a protocol designer as there are
almost no circumstances where a birthday attack results in a major
compromise of my system.
Dobertin demonstrated a birthday attack on MD5 back in 1995 but it had no
impact on the security of certificates issued using MD5 until the attack
was dramatically improved and the second pre-image attack became feasible.
So I would rather that SHA3-256 provide a full 2^256 computational work
factor against pre-image attacks even if there is a birthday vulnerability.
> (3) Don't accept anything without a proof reducing the security of the
>> whole thing down to something overdesigned in the sense of (1) or (2).
>>
>
>
> Proofs are ... good for cryptographers :) As I'm not, I can't comment
> further (nor do I design to them).
Proofs are good for getting tenure. They produce papers that are very
citable.
--
Website: http://hallambaker.com/
--089e0160b99886900304e7eade94
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Oct 3, 2013 at 5:17 AM, ianG <span dir=3D"ltr"><=
;<a href=3D"mailto:iang@iang.org" target=3D"_blank">iang@iang.org</a>></=
span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">
<div class=3D"im">On 2/10/13 17:46 PM, John Kelsey wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Has anyone tried to systematically look at what has led to previous crypto =
failures?<br>
</blockquote>
<br></div>
This has been a favourite topic of mine, ever since I discovered that the e=
ntire foundation of SSL was built on theory, never confirmed in practice. =
=A0But my views are informal, never published nor systematic. Here's a =
history I started for risk management of CAs, informally:<br>
</blockquote><div><br></div><div>I don't understand what you mean there=
. The actual history of SSL was that SSL 1.0 was so bad that Alan Schiffman=
and myself broke it in ten minutes when Marc Andressen presented it at the=
MIT meeting.</div>
<div><br></div><div>SSL 2.0 was a little better but none of the people who =
worked on it had any formal background in security. During the design proce=
ss Netscape finally got a clue and hired some real security specialists but=
one of Andresen's hiring criteria was not to hire anyone from CERN who=
might suggest that the Web had been invented by Tim Berners-Lee rather tha=
n himself so it took them a lot longer than it needed to.=A0</div>
<div><br></div><div>During that time I told them about their random number =
generator design being barfed and they told me they would fix it but they d=
idn't.</div><div><br></div><div>SSL 3.0 was designed by Paul Kocher as =
we all know and he did a pretty good job. But they only gave him two weeks =
to work on it.</div>
<div><br></div><div>I don't think Paul's design was very theoretica=
l and Netscape didn't give him anywhere near enough time to do a full f=
ormal analysis of the protocol, even were that possible with the tools avai=
lable at the time.</div>
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"=
im"><span style=3D"color:rgb(34,34,34)">It is far better to select a target=
such as 128 bit security, and then design each component to meet this targ=
et. =A0If you want "overdesign" then up the target to 160 bits, e=
tc. =A0And make all the components achieve this.</span></div>
</blockquote><div><br></div><div>I don't like that approach to hash fun=
ction design.</div><div><br></div><div>Yes, I know that the strength of a 2=
56 bit hash against a birthday attack is 2^128 but that is irrelevant to me=
as a protocol designer as there are almost no circumstances where a birthd=
ay attack results in a major compromise of my system.=A0</div>
<div><br></div><div>Dobertin demonstrated a birthday attack on MD5 back in =
1995 but it had no impact on the security of certificates issued using MD5 =
until the attack was dramatically improved and the second pre-image attack =
became feasible.</div>
<div><br></div><div>So I would rather that SHA3-256 provide a full 2^256 co=
mputational work factor against pre-image attacks even if there is a birthd=
ay vulnerability.=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">(3) =A0Don't accept an=
ything without a proof reducing the security of the whole thing down to som=
ething overdesigned in the sense of (1) or (2).<br>
</blockquote>
<br>
<br></div>
Proofs are ... good for cryptographers :) =A0As I'm not, I can't co=
mment further (nor do I design to them).</blockquote><div><br></div><div>Pr=
oofs are good for getting tenure. They produce papers that are very citable=
.=A0</div>
</div><div><br></div>-- <br>Website: <a href=3D"http://hallambaker.com/">ht=
tp://hallambaker.com/</a><br>
</div></div>
--089e0160b99886900304e7eade94--
--===============6529117455737057190==
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
--===============6529117455737057190==--
