<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 30, 2014 at 9:28 AM, Jerry Leichter <span dir="ltr"><<a href="mailto:leichter@lrw.com" target="_blank">leichter@lrw.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Jun 26, 2014, at 5:21 PM, John Kelsey <<a href="mailto:crypto.jmk@gmail.com">crypto.jmk@gmail.com</a>> wrote:<br>

> a.  The security benefit of algorithm agility is entirely in being able to *stop* using some algorithms while still functioning.<br>
><br>
> This means that you only really get this benefit if you have at least two ciphersuites that are both SHALLs.  If everyone implements RC4 + CRC32 (the SHALL), and some people also implement AEC-GCM (the SHOULD), then when someone finally realizes that RC4+CRC32 is insecure, you can't actually get rid of it.<br>

</div>But this leads us to an interesting position.  We have two schemes (algorithms, protocols what have you), A and B, that both ends definitely implement and which in other ways (performance, cost) are essentially interchangeable (else, again, we would not be in a position to stop supporting either).  We think both are secure, but one of them *may* have been broken - we just don't know which.<br>

<br>
This is then simple game theory:  We have two strategies, with equivalent payoffs that may be low (if the opponent "chose" to attack the same strategy we chose), or high otherwise.  And game theory tells us that the optimal strategy is a mixed one:  Choose A or B at random with equal probability.  (You can weight the probability to match knowledge of a weighted probability on the opponent's side.)<br>

<br>
So the logical outcome of asking for algorithm agility is ... a single more complex algorithm.<br></blockquote><div><br></div><div>Not really.</div><div><br></div><div>The reason I specify AES as the mandatory to implement algorithm in protocol specifications is that it is the only algorithm currently in use that satisfied all the following criteria:</div>
<div><br></div><div>1) Informed option considers the algorithm to be acceptably secure for all encryption applications.</div><div><br></div><div>2) Is the result of an open selection competition that is generally agreed to have been reasonably transparent and to have made the decision on empirical grounds,</div>
<div><br></div><div>3) Is ubiquitously supported on all platforms including hardware.</div><div><br></div><div>A new more complex algorithm would not meet those criteria. But that is OK because my criteria for a backup algorithm are not the same as my criteria for a default algorithm. I am quite happy with the idea that SHA-2 is the current mandatory to implement algorithm (because even though it was not developed in an open process it is the defacto standard) and SHA3 is the mandatory to implement backup algorithm. </div>
<div><br></div><div>We do need a replacement backup algorithm for symmetric encryption though, it is the only major algorithm class that we do not currently have an acceptable replacement algorithm for. It is easy to see that we will in due course transition from RSA+DH to some variation of ECSignature + ECDH and the only thing holding us back is Patent FUD.</div>
<div><br></div><div>It is about time we had another cryptography competition. And I have at least one sponsor interested in funding part of one. Just about the right time has elapsed since the last one.</div><div><br></div>
<div> </div><div><br></div></div></div></div>