On Mon 30.Nov'15 at 11:37:18 -1000, Brian Smith wrote:
> Julien Vehent <jul...@linuxwall.info> wrote:
> > The original thread  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.
> > 
> > http://email@example.com/msg11247.html
> The discussion above was biased in favor of what was best for FirefoxOS and
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  and  and note how
> client_write_IV/server_write_IV are used.
>  https://www.ietf.org/mail-archive/web/tls/current/msg15573.html
>  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?
dev-tech-crypto mailing list