[Cryptography] On the Impending Crypto Monoculture

Thierry Moreau thierry.moreau at connotech.com
Fri Mar 25 11:48:43 EDT 2016


Nice essay.

One general comment and a few specific observations.

On 24/03/16 12:41 PM, Peter Gutmann wrote:
> On the Impending Crypto Monoculture
> ===================================
>
> A number of IETF standards groups are currently in the process of applying the
> second-system effect to redesigning their crypto protocols.  A major feature
> of these changes includes the dropping of traditional encryption algorithms
> and mechanisms like RSA, DH, ECDH/ECDSA, SHA-2, and AES, for a completely
> different set of mechanisms, including Curve25519 (designed by Dan Bernstein
> et al), EdDSA (Bernstein and colleagues), Poly1305 (Bernstein again) and
> ChaCha20 (by, you guessed it, Bernstein).
>
> What's more, the reference implementations of these algorithms also come from
> Dan Bernstein (again with help from others), leading to a never-before-seen
> crypto monoculture in which it's possible that the entire algorithm suite used
> by a security protocol, and the entire implementation of that suite, all
> originate from one person.
>
> How on earth did it come to this?
>
> The Underlying Problem
> ----------------------
>
> [...]
>
> In adopting the Bernstein algorithm suite and its implementation, implementers
> have rejected both the highly brittle and failure-prone current algorithms and
> mechanisms and their equally brittle and failure-prone implementations.

Once upon a time, IPv4 needed an upgrade (address space limitation made 
it brittle) and 128 bit addresses were seen as a silver bullet ...

As one commentator hinted, replacing the low-level primitives does not 
achieve a great deal towards failure-resilient mechanisms and 
failure-resilient implementations.

With regards to mechanisms, I long wondered why the classical 
authenticated D-H exchange has been ignored in the TLS design (I still 
wonder somehow after I reviewed the question recently). IPSEC and Host 
Identity Protocol (HIP) have it (buried in a pile of standardization 
details). The core lessons are here:

Hugo Krawczyk, "SIGMA: the 'SIGn-and-MAc' Approach to Authenticated 
Diffie-Hellman and its Use in the IKE Protocols", 2003, proceedings of 
Crypto'03 (LNCS Series, Vol. 2729), extended version available at 
http://www.ee.technion.ac.il/~hugo/sigma.html

What is the basic scheme envisioned for authenticated key establishment 
in the new crypto monoculture?

> Consider the simple case of authenticated encryption  [...]
>
> [counter mode encryption] is an
> incredibly brittle mode, the equivalent of the historically frighteningly
> misuse-prone RC4, and one I won't touch with a barge pole because you're one
> single machine instruction away from a catastrophic failure of the whole
> cryptosystem, or one single IV reuse away from the same.

Implementations are a few machine instructions away from a catastrophic 
failure in many ways, in any scheme. Implementers must be ready. Is the 
counter mode pitfall really special in this respect?

Plus any data integrity (including authentication) protection is one 
machine instruction away from ignoring a negative validation result.

> This isn't just
> theoretical, it actually happened to Colin Percival, a very experienced crypto
> developer, in his backup program tarsnap.

I guess every theoretical weakness has seen actual security incidents in 
which it was a root cause.

Regards,

- Thierry


More information about the cryptography mailing list