On Mon 30.Nov'15 at 11:37:18 -1000, Brian Smith wrote: > Julien Vehent <jul...@linuxwall.info> wrote: > > > The original thread [1] had a long discussion on this topic. The DJB batch > > attack redefines the landscape, but does not address the original concerns > > around AES-256 resistance. To me, the main question is to verify whether > > AES-256 implementations are at least as resistant as AES-128 ones, in which > > case the doubled key size provides a net benefit, and preferring it is a > > no-brainer. > > > > [1] > > http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11247.html > > > The discussion above was biased in favor of what was best for FirefoxOS and > FxAndroid.
AES-NI has also removed mosts concerns around bad implementations of AES, so it seems that the attacks we were concerned about two years ago do not apply anymore. > That discussion also didn't account for the emergence of ChaCha20-Poly1305. > I believe it makes more sense for the server to prefer 256-bit cipher > suites than when I wrote in the discussion above, but ChaCha20-Poly1305 > needs to be taken into consideration to account for ARM clients. And > unfortunately most software (OpenSSL in particular) isn't ready for > ChaCha20-Poly1305 yet. ChaCha20 is a different topic entirely, but yes, it's being added to the modern guidelines in the V4 proposal, as the prefered cipher. We will be ready when NSS and OpenSSL are ;) > It may be useful to compare the processing cost of AES-128, AES-256, and > gzip/deflate when making your case. In particular, if you are compressing > every response then the difference between AES-128 and AES-256 probably > doesn't matter much to you. AES-NI is fast enough that we shouldn't have to care: $ openssl speed -evp aes-256-gcm type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256-gcm 385250.93k 983154.24k 2011460.35k 2620519.76k 3048865.79k ARMv8 added support for it, so I'm guessing all apple and android mobiles now support AES-NI, but I am no CPU architecture expert... > Regarding the batch attack mentioned by DJB, make sure you understand how > it does and does not apply to TLS. See [1] and [2] and note how > client_write_IV/server_write_IV are used. > > [1] https://www.ietf.org/mail-archive/web/tls/current/msg15573.html > [2] https://www.ietf.org/mail-archive/web/tls/current/msg16088.html I haven't followed these discussions closely. You're proposal in those threads concerns tls1.3 specifically. Are we concerned about the nonce handling in 1.1 and 1.2? - Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
