On 3/2/13 4:12 AM, ianG wrote:
This one had the talk written out, which makes it a top talk in just that alone:things that bit us, things we fixed and things that are waiting in the grass [slides] Adam Langley (Google) http://www.imperialviolet.org/2013/01/13/rwc03.html
This article surprised me, because it could almost be read as an argument against AES (or even against block ciphers in general). Which seems to contradict the common cryptographic wisdom of "just use AES and be done with it."
Besides the argument about AES having timing side-channels in #9, the room 101 section at the end suggests we should do away with not only CBC, but also AES-GCM, which is commonly touted as the solution to CBC's woes. (He admits it was his most controversial point, and I'm curious how it was received when the talk was given.) But I believe that if we rule out both CBC and AES-GCM ciphersuites in TLS, that leaves us with only RC4. (And indeed, unsurprisingly given the author, RC4 seems to be what Google's sites prefer.)
It seems like we've been told for ages that RC4 is old and busted, and that AES is the one-size-fits-all algorithm, and yet recent developments like BEAST and Lucky 13 seem to be pushing us back into the arms of RC4 and away from AES.
Although cipher suite proliferation is a common criticism of TLS (and indeed, it seems like neither Camellia nor SEED nor ARIA offer any benefit over AES as far as I'm aware, though I'm not a cryptographer), I wonder if there's benefit in adding a ciphersuite for a new stream cipher (such as Salsa20) to TLS, to eventually replace RC4? Such a proposal could at least have clearly-stated goals (faster than RC4 and AES, more secure than RC4, avoiding the side-channel issues and CBC issues of AES), versus the unclear and never-stated goals of yet-another-128-bit-block-cipher.
--Patrick _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
