<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Mar 16, 2014 at 12:33 AM, James A. Donald <span dir="ltr"><<a href="mailto:jamesd@echeque.com" target="_blank">jamesd@echeque.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 Sat, 15 Mar 2014 16:31:05 ianG wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If people stop believing in institutions such as standards bodies,<br>
certification bodies, and governments, the question is, what or whom<br>
will they trust?  And what could actually deliver that trust?<br>
<br>
It seems that without a good answer to that, there isn't much point in<br>
choosing one technical approach versus another.<br>
</blockquote>
<br></div>
Trust individuals.<br>
<br>
As I posted on this list previously:<br>
<br>
Let us have Jon Callas as unelected president for life of symmetric<br>
cryptography, Bernstein as God King of public key cryptography.<br>
<br>
Recall the long succession of Wifi debacles.  Has any committee ever<br>
done anything good in cryptography?<br>
<br>
IEEE 802.11 was stupid.  If NIST  was not stupid, it was because evil<br>
was calling the shots behind the scenes, overruling the stupid.</blockquote><div><br></div><div>One of the side discussions that came up at the STRINT workshop was on the need for better management of crypto algorithms in standards.</div>
<div><br></div><div>[I am working on the draft I agreed to write some time ago but hadn't finished. It is almost done this time.]</div><div><br></div><div><br></div><div>Right now we have a fairly well established mandatory to implement set:</div>
<div><br></div><div>AES-128, SHA2-256, HMAC-SHA2-256, [DH & RSA-Encrypt], RSA-Signature</div><div><br></div><div>The use of RSA-Encrypt turns out to be redundant in Internet protocol use as we never actually need public key encryption, what we actually use is Key Exchange. Which is good since we don't have a EC version of RSA :-( so we are going to need to to EC-DH anyway.</div>
<div><br></div><div><br></div><div>Although that set is pretty well established it is starting to look a little on the old side. We have a consensus replacement for SHA2 but right now we don't have solid consensus on replacements for anything else.</div>
<div><br></div><div>It seems that we are pretty close to a consensus on the use of EC as the next generation digital signature algorithm. But there are a few more degrees of freedom there which need to be nailed down. There is the choice of curve in particular which is now subject to a lot of possibly justified paranoia.</div>
<div><br></div><div>So we can hypothesize a backup set of algorithms:</div><div><br></div><div>??, SHA3, HMAC-SHA3 / ??-CCM, ECDH, ECDSA</div><div> </div></div><div><br></div><div>Spot the problem? We currently have no backup for an encryption algorithm.</div>
<div><br></div><div>We really do need a backup for that slot and I don't think we can just take one of the AES runners up. The criteria for a reserve algorithm are not the same as for the default. Since the idea is that you can depend on the reserve algorithm even if the default is broken, it has to be tuned for security rather than performance.</div>
<div><br></div><div><br></div><div>I can't see how to get there unless we run a whole new crypto algorithm competition.</div><div><br></div><div>Maybe that is something the Brazilians might want to take on.</div><div class="gmail_extra">
<br></div><div class="gmail_extra"><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>