<div dir="ltr">Hello,<br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-15 20:39 GMT+02:00 Joe St Sauver <span dir="ltr"><<a href="mailto:joe@oregon.uoregon.edu" target="_blank">joe@oregon.uoregon.edu</a>></span>:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
David commented:<br>
<br>
#Why getting rid of longer keys?? Probably the people who should take care<br>
#of using AES128 instead of AES256 shouldn't stick to our document only.<br>
#<br>
#On the other side, AES256 could be consider to be at least as secure as<br>
#AES128.  I don't see any reason to exclude it because it's safer...<br>
#<br>
#For me we HAVE to exclude unsecure algorithm but we SHOULD keep variation<br>
#of algorithm that are at least as secure as the minimal version we keep.<br>
#<br>
#On top of that, it's also possible that some people exclude AES128 for some<br>
#reasons and offering a longer set of algorithm COULD in some case increase<br>
#the compatibility.  That's probably not frequent but who knows...<br>
#<br>
#So in short, I would keep AES256 and add AES196 ;).<br>
<br>
What's the design basis (time horizon) for the choice? For example,<br>
are you worried about a ten year horizon? twenty years? thirty years?<br></blockquote><div><br></div><div>I fully agree on this ;).</div><div>My point is that we should not exclude a variation of an algorithm just because he is "too" good ;).<br>

</div><div><br></div><div>The only big disadvantage I saw with AES256 is from time to time compatibility issues.</div><div>iPhone VPN for instance doesn't support AES256 (at least it was the case on iOS 6).</div><div>

<br></div><div>Java JDK doesn't permit to cipher with AES256 except on Mac OS X (at least when Apple was packaging the JRE).</div><div><br></div><div>Kr,</div><div><br></div><div>David</div></div><div><br></div>-- <br>

David DURVAUX
</div></div>