<div dir="ltr">On Thu, Oct 3, 2013 at 5:17 AM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2/10/13 17:46 PM, John Kelsey wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #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 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:<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 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. </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 didn'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 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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="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 target.  If you want "overdesign" then up the target to 160 bits, etc.  And make all the components achieve this.</span></div>
</blockquote><div><br></div><div>I don't like that approach to hash function design.</div><div><br></div><div>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. </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 computational work factor against pre-image attacks even if there is a birthday vulnerability. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(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).<br>

</blockquote>
<br>
<br></div>
Proofs are ... good for cryptographers :)  As I'm not, I can't comment further (nor do I design to them).</blockquote><div><br></div><div>Proofs are good for getting tenure. They produce papers that are very citable. </div>
</div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>