[cryptography] Workshop on Real-World Cryptography

ianG 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)
>>
>>         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



More information about the cryptography mailing list