[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