The prospect of a crypto monoculture

Peter Gutmann is a well-known participant in encryption-oriented discussions; he is also the author of Engineering Security [814-page PDF]. He recently stirred up some discussion with a posting titled On the impending crypto monoculture. Therein, he states, a number of IETF groups are currently working on a set of redesigned cryptographic standards with an interesting common theme:

For added fun, Daniel is also the author of the reference implementations for these algorithms. So, Peter says, we are heading toward "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." He doesn't really get into the consequences of this situation; it is implicitly understood to be something other than a good outcome.

The posting does go into considerable detail on how this situation came about; it is worth reading in its entirety. In short: there is a strong desire to leave current algorithms and implementations behind because they have been proved, repeatedly, to be brittle and failure-prone. "Anyone who works with crypto on the Internet has had to endure 15-20 years of constant breakage of the crypto they use, both of the algorithms and mechanisms and of the implementations." He mentions Google in particular, since Google is a major participant in the IETF standards process; the company has gotten tired of having to deal with a new attack every few months and would like to transition to something more robust.

While "fanboyism" is a part of why Daniel's algorithms and code are on the ascendant, Peter says, there is more to it than that. In short, the alternatives are either brittle and failure-prone themselves, or they are patent-encumbered and unusable. There is no effective competition to Daniel's work in the real world. Or, to put it a bit more graphically:

As a result, he says, the move toward a monoculture isn't really a vote for Daniel and his work; it's a vote against everything else out there.

Is this a problem?

Peter does not get into why a cryptographic monoculture would be a problem, perhaps because some of the disadvantages are fairly clear to see. If Daniel proves, over time, to have some sort of blind spot, all of his work, at either the algorithmic or implementation level, could prove to be affected. If he turns out to have been in the pay of some nation's security apparatus, the consequences could even be worse — though, in this regard, at least, Daniel somehow seems like a safer bet than many. Either way, some sort of systemic flaw in Daniel's work could lead to a situation where there are no safe algorithms to fall back on.

On the other hand, a wide range of unrelated algorithms has not necessarily proved to be safer. They lead to a dispersal of effort and review time so that, seemingly, none of them reach a level of maturity that allows them to be trusted.

There are examples both ways. Of the things that keep system administrators awake at night, a remotely exploitable OpenSSH bug must be near the top of the list. For all practical purposes, OpenSSH is a monoculture; it is, by far, the dominant SSH implementation. A vulnerability in OpenSSH could lead to the compromise of vast numbers of systems. Such vulnerabilities have been rare, though, as the result of a high-quality implementation and a great deal of code review (though the recent "roaming vulnerability" makes one wonder what else the reviewers might have missed). As a result, one does not often hear people worrying about the OpenSSH monoculture.

On the other hand, OpenSSL is the focus of more concern; there have been a few times when it might have been nicer to have a more diverse set of widely deployed TLS implementations in use. Indeed, there are now a number of projects working in an attempt to provide that diversity. One can argue about that the problems with OpenSSL stem from within the project itself, but its near-monoculture status ensured that those problems affected a large portion of the net as a whole.

Given that a new set of cryptographic standards could end up underpinning security across the net, it is natural, and wise, to be worried about building the whole thing on the work of one person. There is simply too much at stake to take the risk of a widespread vulnerability with no fallback available. One hopes that Peter's warning will be taken seriously — and that, somehow, an alternative to a monoculture will emerge from somewhere.

Note: you can avoid this step in the future by logging into your LWN account.