<div dir="ltr">Mmmm...<div><br></div><div>Why getting rid of longer keys?? Probably the people who should take care of using AES128 instead of AES256 shouldn't stick to our document only.</div><div><br></div><div>On the other side, AES256 could be consider to be at least as secure as AES128.  I don't see any reason to exclude it because it's safer...  </div>

<div><br></div><div>For me we HAVE to exclude unsecure algorithm but we SHOULD keep variation of algorithm that are at least as secure as the minimal version we keep.</div><div><br></div><div>On top of that, it's also possible that some people exclude AES128 for some reasons and offering a longer set of algorithm COULD in some case increase the compatibility.  That's probably not frequent but who knows...</div>

<div><br></div><div>So in short, I would keep AES256 and add AES196 ;).</div><div><br></div><div>Kr,</div><div><br></div><div>David</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-13 21:04 GMT+02:00 ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>></span>:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 13/05/2014 19:31 pm, Aaron Zauner wrote:<br>
> Ok, I've come up with the following B cipherstring:<br>
><br>
> ```<br>
> EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA<br>


> ``<br>
><br>
> This works for all versions that I've tested (0.9.8+).<br>
><br>
><br>
> Another issue I'd like to discuss:<br>
><br>
> There's still a thing that bothers me a bit, we're using AES256<br>
> everywhere, there are very little devices that will not support this,<br>
> which means that either:<br>
><br>
>       - we can get rid of AES128 completely<br>
>       - we can get rid of AES256 completely<br>
><br>
> I'd opt for the second option, we sill have a A cipherstring that serves<br>
> only AES256, there's really no need to have it in our B cipherstring.<br>
> Even if quantum computers become a reality (which is unlikely for the<br>
> next decades - but don't believe me, hear it from schneier [0]) AES128<br>
> provides around (2^128)/2 security (brute force in a quantum computer)<br>
> [1]. This would also shorten our cipherstring and as such make it<br>
> possible for use in software that has a restricted character limit for a<br>
> cipherstring option (such as OpenVPN).<br>
><br>
> Any input on that? I don't think it does weaken our B recommendation -<br>
> it simplifies it.<br>
<br>
<br>
</div>Yep, get rid of AES256.  Anyone who needs the difference shouldn't be<br>
here :)<br>
<br>
iang<br>
<br>
_______________________________________________<br>
Ach mailing list<br>
<a href="mailto:Ach@lists.cert.at">Ach@lists.cert.at</a><br>
<a href="http://lists.cert.at/cgi-bin/mailman/listinfo/ach" target="_blank">http://lists.cert.at/cgi-bin/mailman/listinfo/ach</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>David DURVAUX
</div>