[cryptography] Fwd: [gsc] Fwd: OpenBSD IPSEC backdoor(s)

Sandy Harris sandyinchina at gmail.com
Wed Dec 15 20:11:20 EST 2010

On Thu, Dec 16, 2010 at 4:38 AM, Jon Callas <jon at callas.org> wrote:
>> That said, I would not recommend people to write their own crypto, as
>> cryptography is hard enough to foster any kind of fault, glitch or
>> defect. In turn, this may leads to incidents that promise to be no
>> less severe than those arising from a backdoor in OpenBSD IPSec stack,
>> if any.
> Perhaps a bit more succinctly, the best way to eavesdrop on someone is to tell them that their crypto is broken.

There are at least two things that make putting a backdoor into any of the open
source implementations of a major protocol difficult. I am not saying
just quite difficult.

First, it is open source. The code can be audited, and anyone with really
serious security concerns might do that. Not all, of course; people may
be lazy, busy, or whatever. Also, perhaps not all auditors will be really
competent. But if even one competent auditor takes a careful look, it
becomes quite difficult for a backdoor to hide. Perhaps not impossible,
see http://cm.bell-labs.com/who/ken/trust.html, but hard.

Second, it implements a well-specified protocol, and interoperation
with other implementations is routinely tested by both implementaion
teams and users. This can turn up all sorts of oddities.

For example, at one point the FreeS/WAN & PGPnet versions of
IPsec used slightly different versions of RSA (T = (p-1)*(q-1) versus
T = lcm(p-1,q-1)) and at one point, Microsoft's implementation
would someimes silently switch to single DES even if the admin
had specified 3DES (arguably a back door). Interoperation
testing caught these and many other problems.

That said, there are quite a few ways to compromise IPsec
without violating the protocol in any obvious way. Some are
obvious -- using a covert channel to reveal keying material,
or either weakening or leaking the random numbers in the
Diffie-Hellman key agreement. There are likely more.

More information about the cryptography mailing list