[cryptography] Workshop on Real-World Cryptography
iang at iang.org
Mon Mar 4 01:05:14 EST 2013
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)
> 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
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 .
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
> 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
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
More information about the cryptography