[Ach] Vote for new Cipherstring B [Was: Issue with OpenSSL >0.9.8l]
Joe St Sauver
joe at oregon.uoregon.edu
Thu May 15 20:39:09 CEST 2014
#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?
That terrific little tool at http://www.keylength.com/en/compare/
allows you to readily play with various thresholds. If you're a twenty
year sort of person, for example, and you look at recommendations for
2035, the suggestion is that a 128 bit symmetric would be sufficient.
That said, I also totally get folks who might want something more "just
in case." Conservatively choosing AES-256 doesn't strike me as being
at all crazy (at least if you worry about quantum crypto, or you just
like running with a safety margin, or the unknowns are overwhelming
folks, or it's more about the optics than the math, etc.)
All that said, I'm not sure I see a lot driving folks towards doing
More information about the Ach