<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 14, 2015 at 11:30 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 14/08/2015 20:15 pm, ianG wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So if people want to go full IoT, can we ask: what does that mean? Can<br>
we draw the line and say the OpenPGP offering here is CipherSuiteIoT<br>
which means x/y/z in numbers and params and no more no less?<br>
<br>
PHB:<br>
> IOT looks set to create a demand<br>
> for an absolutely minimal cryptographic<br>
> suite. One signature algorithm, one<br>
> exchange algorithm, both on the same<br>
> curve, one authenticated encryption<br>
> mode, one digest/pseudorandom function.<br>
<br>
<br>
Or are we offering full cipher flexibility to those IoT designers, and<br>
thus forcing them to implement all the multiples, because they won't<br>
know what other designers will choose, etc?<br>
<br>
My thinking right now is that (assuming we're doing this) we should put<br>
in the draft a recommendation that precisely identifies a minimum<br>
most-popular obligatory to implement suite that covers as far down as we<br>
can get it. And leave the rest up to the market?<br>
</blockquote>
<br>
<br>
<br></span>
Wait - I'm on the wrong bloody list .. this was supposed to be a message to OpenPGP. Oh well.</blockquote><div><br></div><div>Actually, it might be better to have that conversation here.</div><div><br></div><div>Something that really worries me about the OpenPGP discussion is the tone of the discussion is 'prove to me that this attack is a problem' not 'prove to me that this attack is not a concern'. </div><div><br></div><div><br></div><div>I think the IoT space is so diffuse that we risk ending up talking nonsense. I see three distinct classes of machine:</div><div><br></div><div>1) Effectively unconstrained. Any desktop, smartphone or tablet. Anything at or above Raspberry Pi capabilities.</div><div><br></div><div>2) Demanding thought and care</div><div><br></div><div>3) Ridiculously underpowered. Anything with an 8 bit core.</div><div><br></div><div><br></div><div>Yes, there will be devices in the third category. But guess what, they don't have to do public key at all. Or if they do they only need do it during one time initialization.</div><div><br></div></div>The hard bit is the bit in the middle. And even Windows 10 IoT is likely to pose issues. Yes, you can use a Raspberry Pi2 to develop and the chip at the center of the device only costs a buck. But that is a development environment. If you went into production you would want to go for the lowest power, lowest cost or otherwise best chip you can find.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Raspberry Pi can easily do AES256. But you might well want to ask yourself if you really, really need AES128 and AES256. Every module you add to your device means more memory, longer startup times and so on.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Right now we do have a defacto consensus algorithm suite:</div><div class="gmail_extra"><br></div><div class="gmail_extra">SHA-2-256</div><div class="gmail_extra">HMAC-SHA-2-256</div><div class="gmail_extra">AES128 CBC<br></div><div class="gmail_extra">RSA-2048</div><div class="gmail_extra">ECDH-256</div><div class="gmail_extra"><br></div><div class="gmail_extra">The main problem with this set is the RSA part and in particular key generation which is difficult and painful. The strength is not ideal either and RSA really hits diminishing returns above 2048 bits.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think we will settle on a new defacto consensus. But I think its going to be centered on the 256 bit algorithms:</div><div class="gmail_extra"><br></div><div class="gmail_extra">SHA-3-512</div><div class="gmail_extra">AES256-GCM</div><div class="gmail_extra">CFRG-SIG-448</div><div class="gmail_extra">CFRG-DH-448</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>