<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Mar 16, 2014 at 4:44 PM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</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>On 16/03/2014 12:40 pm, Phillip Hallam-Baker wrote:<br>
> On Sun, Mar 16, 2014 at 12:33 AM, James A. Donald <<a href="mailto:jamesd@echeque.com" target="_blank">jamesd@echeque.com</a>>wrote:<br>
>> On Sat, 15 Mar 2014 16:31:05 ianG wrote:<br>
</div>>>> If people stop believing in ...<br>
>> Trust individuals.<br>
<div>> One of the side discussions that came up at the STRINT workshop was on the<br>
> need for better management of crypto algorithms in standards.<br>
</div>...<br>
<div>> So we can hypothesize a backup set of algorithms:<br>
><br>
> ??, SHA3, HMAC-SHA3 / ??-CCM, ECDH, ECDSA<br>
<br>
<br>
</div>First question -- when was a backup suite last successfully fielded?<br></blockquote><div><br></div><div>Actually that was the case for TLS which required MD5 and SHA1 in the first incarnation. So when MD5 was found to be faulty, the switch to SHA1 was painless.</div>
<div><br></div><div><br></div><div> </div><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">
Second question -- what proportion of problems are addressed by a suite algorithm?<br></blockquote><div><br></div><div>Every IETF crypto protocol has specified a mandatory to implement algorithm to ensure a minimal level of interoperability. If the spec designers don't choose one cipher the market will - and we may not like the choice.</div>
<div><br></div><div> </div>
<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">
Which is to say, in challenging your assumptions, I'm not sure your<br>
going to get any benefit form the huge amount of work you need to do to<br>
handle a backup suite.<br></blockquote><div><br></div><div>IETF already requires algorithm agility so there is no more complexity.</div><div><br></div><div>Today there is no backup algorithm specified so the tendency is that implementations offer the kitchen sink. Which does not work because security is determined by the least secure algorithm. </div>
<div><br></div><div>Specifying one required and one recommended algorithm as backup means there is a chance that might be all the implementations support unless there is good reason.</div><div> </div><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">
Another indicator is this: when you come to launch the backup<br>
algorithm, will everything have changed?<br></blockquote><div><br></div><div>No, we have had pretty good notice of past issues.</div><div><br></div><div> </div><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">
Since I last designed a packet suite using AES/SHA1/HMAC, we have<br>
shifted over to a fanboy consensus of ChaCha20/Poly1305; which as it<br>
happens is a stream-based mechanism, so the code to implement it looks<br>
entirely different.<br></blockquote><div><br></div><div>I don't think the IETF are fans of stream ciphers or anything that looks like one.</div><div><br></div><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">
So, in a sense, there is an emerging consensus that competitions are<br>
what we need to re-establish trust in a process. h/t to Ralf as well.<br>
<br>
That isn't going to go away. We're kind of left with a sense that we<br>
need a competition for every darn problem we have. So why not do that?<br>
<br>
Why not start COMPETE 2014 -- the yearly event for crypto competitions?<br></blockquote><div><br></div><div>Well, they take five years for a start.</div><div> </div></div><div><br></div><div><br class="">On Sun, Mar 16, 2014 at 3:23 PM, Jerry Leichter <span dir="ltr"><<a href="mailto:leichter@lrw.com" target="_blank">leichter@lrw.com</a>></span> wrote:<br>
</div><div><br></div><div>>I don't buy that contention. It certainly doesn't describe the relationship of <br>>EC to RSA - I haven't heard any claims that EC is inherently more secure <br></div><div>>than RSA (in fact one might argue that the underlying hard problem in EC </div>
<div>>is less well-understood than the one in RSA); rather, the claim is that RSA </div><div>>is becoming too slow to be practical to retain adequate security in the </div><div>>face of advances in attacks, while EC gets by with much smaller keys </div>
<div>>(hence gets much better performance) at the required level of security.<br><br>It isn't that EC is stronger the reason it is interesting is that RSA key size stops delivering interesting improvements in strength after about 2048 bits.<br>
<br><br>>A fallback for AES with significantly worse performance simply wouldn't be >used. People put as much hardware as needed out there to solve a >problem; they don't add a whole bunch extra "just in case". <br>
</div><div><br></div><div>Not any more, its now a cloud thing. If more computing grunt is required they will up their server farm size as necessary to deploy it.</div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/" target="_blank">http://hallambaker.com/</a><br>
</div></div>