3 ms·
For the future, there's also the encrypt-then-MAC extension (https://tools.ietf.org/html/rfc7366 https://tools.ietf.org/html/rfc7366, https://bugzilla.mozilla.o
by cesarb 12y ago
For the future, there's also the encrypt-then-MAC extension (https://tools.ietf.org/html/rfc7366 https://tools.ietf.org/html/rfc7366, https://bugzilla.mozilla.org/show_bug.cgi?id=972145 https://bugzilla.mozilla.org/show_bug.cgi?id=972145), and probably some variant of a ChaCha20+Poly1305 AEAD (https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-0..., https://bugzilla.mozilla.org/show_bug.cgi?id=917571 https://bugzilla.mozilla.org/show_bug.cgi?id=917571, already on Chrome AFAIK).
For now, AES-GCM is the best alternative.
- edwintorok 12y agoI like the alternative described here: https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto... "The end result is that Chrome talking to Google uses AES-GCM if there's hardware support at the client and ChaCha20-Poly1305 otherwise." It seems to be specific to Chrome though, and all TLS clients would have to reimplement that choice. Would be good if there was a way to tell the SSL library to give you the best cipher that works on your hardware (i.e. don't give AES-GCM/AES-CBC when there is no hardware support and the software implementation isn't constant time).