On 4/03/13 06:05 AM, Patrick Pelletier wrote:
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."
That is only managerial acronym blather, it isn't wisdom. Managers see
the words 'AES' and 'RSA' and numbers like 128 and 2048 and feel
confident their job is done. We sometimes flippantly call this
cryptographic numerology.
In reality, it is *always* AES+some-mode+some-maccing. And therein lies
a mess which managers don't go in to.
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.
Yeah, the encryption field is in flux, again, and it's somewhat bemusing
that we are on the other side of a successful competition to create a
good algorithm -- yet we're already in rebellion.
But, the problem is more a realisation that requirements have changed,
in game-changing ways, than that the old work was bad. It's perhaps
best seen as a time-line of black boxes.
For much of the latter part of the last century, the block cipher was
considered the black box of interest. But gradually simplistic use of
this fell out of favour, and modes became interesting. Note the
flippantly-named ECB mode.
In the early 90s, we were into block ciphers and modes. As long as we
learnt DES and CBC, we achieved the honourific of 'crypto expert'. As
the 90s ended and into the 00s, we had to upgrade our knowledge with HMACs.
Then, in the early 00s, the term 'authenticated encryption' became
popular. Later on, perhaps the late 00s, it was also realised that
there were no packets that were 16 bytes long, and indeed the whole
notion of a block cipher was a historical convenience dating back to the
typewriter construction of engima-style machines. Remember the DES 8
byte cipher? And the 56 bit key, and 7 bit ASCII?
(Does anyone know what the thinking behind 8 byte blocks was?)
We can see this realisation -- that nobody types out an IP packet these
days -- in Keccak's sponge function. Perhaps it was the MD5/SHA1
internal blocking and how it broke with certificates that triggered it
(I reading the runes here) but the requirements have now shifted to the
point where a block cipher is no longer relevant.
We need a variable-length, authenticated encryption function.
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),
In the 1990s there was a cry for crypto-freedom that we all fell for,
like coffee or beer or pot, there was no too-much here. The feeling was
strong that we wanted to have the freedom to choose and tinker with our
own crypto choices, this was our right. Dammit!
Unfortunately it also played into the hands of our nameless faceless
bogeyman enemy, because it created a bureaucratic nightmare that left
open chinks through complexity, and it also slowed down the deployment
of crypto in a dramatic way. For an amusing reference [0].
Anyone here care to speculate what algorithm agility costs us? To my
mind, it probably doubles the cost of the software. Which in more
concrete terms probably halves the chance of deployment, and halves the
user base growth. (That's without considering the introduction of
weaknesses.)
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.
Perhaps, the goals we now have are met more easily by a stream cipher
than by a block cipher? Hence the fascination with counter modes.
But really, what has happened is that the wider 'modes' part of software
engineering (including hmacs) has now been kicked back, by the software
engineers, or taken back, to the cryptographers. Perhaps by mutual
agreement. The complexities of us cryptoplumbers building a suitable
variable-length authenticated cipher have made us all realise that
actually a new black box would be better. (Perhaps google has realised
that the complexities of just turning on a good cipher suite within TLS
are such that RC4 emerges as simplicity favourite...)
As an aside, there is also an emerging consensus about
committee-protocolism as being the wrong way to go about
industrial-scale security. Note Adam Langley's remark:
So, for new primitives, you may want to produce solid
implementations for different platforms to seed the
implementation ecosystem. Not just reference
implementations, but ones that are good enough that
they dominate the set of implementations. For example,
if I specify curve25519 in a protocol, I can be pretty
sure that everyone is going to be using djb's reference
code. That's a major advantage.
It's about simplifying the engineering of cryptoplumbing so we can get
to the point where one person can create the majority of the
implementation. Reliably.
iang
[0] http://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
