[cryptography] the spell is broken

ianG iang at iang.org
Sat Oct 5 07:03:38 EDT 2013

On 4/10/13 10:52 AM, Peter Gutmann wrote:
> Jon Callas <jon at callas.org> writes:
>> In Silent Text, we went far more to the "one true ciphersuite" philosophy. I
>> think that Iang's writings on that are brilliant.
> Absolutely.  The one downside is that you then need to decide what the OTS is
> going to be.  For example Mozilla (at least via Firefox) seems to think it
> involves Camellia (!!!?!!?).

Thanks for those kind words, all.  Perhaps some deeper background.

When I was writing those hypotheses, I was very conscious that there was 
*no silver bullet*.  I was trying to extrapolate what we should do in a 
messy world?

We all know that too many ciphersuites is a mess.  We also know that 
only one suite is vulnerable to catastrophic failure, and two or three 
suites is vulnerable to downgrade attacks, bugs in the switching, and 
expansion attacks in committee.

A conundrum!

Perhaps worse, we know that /our work is probably good/ but we are too 
few!  We need ways to make cryptoplumbing safe for general software 
engineers, not just us.  Not just hand out received wisdom like "use 
TLS" or follow NIST.  If we've learnt anything recently, it is that 
standards and NISTs and similar are not always or necessarily the answer.

There are many bad paths.  I was trying to figure out what the best path 
among those bad paths was.  From theory, I heard no clarity, I saw noise.

But in history I found clues, and that is what informs those hypotheses.

If one looks at the lifecycle of suites (or algorithms, or protocols, or 
products) then one sees that typically, stuff sticks around much longer 
than we want.  Suites live way past their sell-by date.  Once a 
cryptosystem is in there, it is there to stay until way past 
embarrassing.  Old, algorithms, old suites are like senile great-aunts, 
they hang around, part of the family, we can't quite see how to push 
them off, and we justify keeping her for all sorts of inane reasons.

Alternatively, if one looks at the history of failures, as John Kelsey 
pointed to a few days ago, one sees something surprising:  rarely is a 
well-designed, state of the art cryptosuite broken.  E.g., AES/CBC/HMAC 
as a suite is now a decade old, and still strong.

Where things go wrong is typically "outside" the closely designed 
envelope.  More, the failures are like an onion:  the outside skin is 
the UI, it's tatty before it hits the store.  Take the outer layer off, 
and the inner is quite good, but occasionally broken too.  If we keep 
peeling off the layers, our design looks better and better....

Those blemished outer onion layers, those breaks, wherever they are, 
provide the next clue in the puzzle.  Not only security issues, but we 
also have many business issues, features, compliance ... all sorts of 
stuff we'd rather ignore.

E.g., I'm now adding photos to a secure datagram protocol -- oops!  SSL 
took over a decade for SNI, coz it was a feature-not-bug.  Examples 
abound where we've ignored wider issues because it's SOPs, 

Regardless of what we think or want, if we are really being responsible 
for the end-user result, we would be faced with pressures to do 
wholesale fixes.  And these fixes will come more from the outside of the 
onion than from inside.  Therefore, I claim:

    The cryptoplumber will be pressured to replace the system
    well before needing to replace any particular crypto component.

Add in more issues:  Resources -- I haven't got a team to spend on 
tweaking.  Better knowledge over time -- we know so much more now. 
Incompatibility nightmares.  Then, it becomes clearer that the big 
picture is rarely about a cryptosuite, it's about the whole darn system.

Hence, I say:

    Plan on replacing the whole lot, when it is needed.

Which leads to the corollary:

    Do a good job:  make it Good as well as True!

And you likely won't need a second.  And another corollary:

    Prepare the next generation in background time.
    In your sleep, on the train, on honeymoon...
    Be advanced, be ready!

In the rarest of circumstances that you do need to replace a 
cryptosuite, just replace the whole darn lot.  It'll be about time, anyway.

>> One True Suite works until that suite is no longer true, and then you're left
>> hanging.
> One way to deal with this that got discussed some time ago over dinner (dining
> geeks, not cryptographers) is to swap at random among a small number of
> probably-OK suites and/or algorithms, a sort of probabilistic-security defence
> against the OTS having a problem.  It's not like there's a shortage of them
> in... well, SSH, SSL/TLS, PGP, S/MIME, etc, anything really.

For some reason, I'm wondering what the optimal method for a random 
shuffle of dinner choices/plates is, and how the vegetarians are going 
to respond...


More information about the cryptography mailing list