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

Reply via email to