[Ach] Vote for new Cipherstring B [Was: Issue with OpenSSL >0.9.8l]

[David Durvaux]

Hello,


2014-05-15 20:39 GMT+02:00 Joe St Sauver <joe at oregon.uoregon.edu>:

> Hi,
>
> David commented:
>
> #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.
> #
> #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...
> #
> #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.
> #
> #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...
> #
> #So in short, I would keep AES256 and add AES196 ;).
>
> What's the design basis (time horizon) for the choice? For example,
> are you worried about a ten year horizon? twenty years? thirty years?
>

I fully agree on this ;).
My point is that we should not exclude a variation of an algorithm just
because he is "too" good ;).

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

Java JDK doesn't permit to cipher with AES256 except on Mac OS X (at least
when Apple was packaging the JRE).

Kr,

David

-- 
David DURVAUX
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/ach/attachments/20140516/870f576f/attachment.html>