Hi, On Tue, 18 Nov 2014, Viktor Dukhovni commented on some feedback from me that Stephen Farrell had kindly passed along:
> > 4.2.1 states that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 SHOULD > > be the first cipher proposed, and servers SHOULD prefer that > > cipher whenever is proposed. > > > > I'd prefer to see the AES_256 version recommended instead, given > > that it provides a large margin of cryptographic strength. > > The cryptographic margin in AES-128 is I believe quite sufficient > for best current practice. The performance benefits can lead to > greater adoption. Don't let the perfect be the enemy of the good. To be explicit, my preference for AES-256 over AES-128 is a function of three factors: 1) The NSA requires AES-256 in Suite B for TOP SECRET content. That implies to me that at least under some circumstances, some smart folks think that AES-128, even though good, just isn't good *enough* That may reflect the fact that TOP SECRET content may need to stay protected for fifty years (and that's a long time), or it may be related to something else (like worries about quantum computing), but at least for some content, we know that AES-128 isn't believed to be good enough. See https://www.nsa.gov/IA/Programs/suiteb_cryptography/ [I'm not cleared and I'm not doing anything classified, but why not think like an civil engineer and build in a margin of safety, eh?] 2) There's some indication that the reason why the NSA mandates AES-256 actually *is* concern around the risk of quantum crypto, see for example https://twitter.com/SteveBellovin/status/311545287313330176 Given a $10.8 billion dollar budget for the Consolidated Cryptology Program (see for example www.wired.com/2013/08/black-budget/ ), I'd expect a bit of progress, and heck, who knows, they may have made better progress than is generally known. If that's the case, AES-256 would be a better option than AES-128, for the reasons discussed at http://en.wikipedia.org/wiki/Key_size#Effect_of_quantum_computing_attacks_on_key_strength 3) The performance penalty I'm seeing isn't big enough to be a show stopper for most use cases. Testing with openssl speed aes-128-cbc (etc) on even a basic laptop, I'm seeing: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 111191.87k 121014.21k 123128.49k 123900.23k 123483.48k aes-256 cbc 82304.19k 87485.03k 89003.26k 89442.30k 89513.98k If that performance hit is a big deal for a particular situations, by all means fall back to AES-128, but in cases where there's still plenty of computational "pedal" left under your foot, why not push harder and use it? Naturally, if AES-256 were to actually have *issues* that AES-128 *doesn't* (and I'd note that periodically I've seen things like https://www.schneier.com/blog/archives/2009/07/another_new_aes.html ), well, that would be a different matter. Is *that* the concern that folks have with prioritizing AES-256 over AES-128? Regards, Joe St Sauver ([email protected] or [email protected]) Farsight Security _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
