[cryptography] the spell is broken
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
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.
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
> 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
More information about the cryptography