Recently there is a bit of concern over encryption back doors in IPsec and while the status of this has not been confirmed, I don't know what impact something like this might have.

For instance, does this mean that, since encryption on this layer may be compromised, we have vulnerabilities on various platforms of internet technology (for example, SSL)?

What does a working back-door here permit in terms of Eve and Mallory attacks?

  • I'm not overly familiar with the security.se community, if this is out of scope let me know and I'll delete this.
    – Incognito
    Commented Dec 15, 2010 at 15:25
  • 1
    I think you're on topic. That said, your question could be more specific about what implications you want to find out about.
    – user185
    Commented Dec 15, 2010 at 17:14

5 Answers 5


I think the biggest impacts will be on the public relations side.

On the plus side (from OpenBSD maintainers point of view), the idea that the FBI deemed OpenBSD important enough, back in 2000, to warrant money-backed insertion of backdoors, is a sure ego inflater. This alone could be a motive for public allegations of backdoors, whether they exist or not. Also, the apparent immediate and full disclosure is a nice PR job.

On the minus side, OpenBSD communication has long been about how much more secure OpenBSD was than any other system, thanks to proactive security auditing and numerous internal code reviews. Finding a ten-year old backdoor right in the middle of cryptographic network code would kind of deflate the myth a bit.

Now, on the technical side...

There are many ways a subtle alteration of the code could constitute a "backdoor". If I were to implement a backdoor myself, I would try to rig the pseudo-random number generator. It is relatively easy to make a PRNG look like it produces cryptographic-quality output, but with, in reality, low internal entropy (e.g. 40 bits). This would make IPsec-protected communications vulnerable to decryption with common hardware and a passive-only attacker (thus undetectable). Also, a flawed PRNG can be attributed to incompetence (because making a bad PRNG is easy, but making a good one is not), opening the road to plausible deniability.

Another backdooring method is data leakage. For instance, whenever you have some random bits in some network packet, you can arrange for these bits to actually contain data about the internal system state. A good backdoor can thus leak secret encryption keys, to be picked up by anybody aware of the existence of the leakage.

Potential buffer overflows are crude backdoors, since they can be exploited only by active attackers, which is risky. Spy agencies usually abhor risks. If such bugs are found in OpenBSD code, I think it is safe to state that they are "true" bugs, not malicious holes.

  • Can you explain how they could create a side-channel vulnerability? I understand the idea about leaking data, but how would one do that and how would an attacker get the leaked data? Commented Dec 17, 2010 at 17:56
  • 2
    For instance, when using 3DES encryption in IPsec, as described in RFC 2405, the encrypted data payload begins with a random IV, i.e. 8 data bytes which are transmitted in the clear. They are supposed to be selected randomly and uniformly. A malicious sender could use those bytes to "publish" some data, e.g. a copy of eight of the bytes of the actual secret key. An outsider spy then just has to capture some packets to get the key. Commented Dec 17, 2010 at 20:05

As I noted in comment, this is a very broad question. There are a wide variety of potential ramifications. One thing is clear though: Theo just got himself a whole bunch of free code reviews ;-).

Maybe the FBI did manage to get a backdoor into the 2001-era openbsd IPSec code. If they did, it means that there have been VPNs that US law enforcement could snoop on. Now whether they did depends on whether anyone deployed the VPN in its snoopable configuration, whether the FBI detected that deployment, and whether they cared.

Maybe the backdoor is still there. All this means is that you can increase the count of at-risk installations. Especially if any other operating systems took their IPSec code from OpenBSD...FreeBSD, Mac OS X and iOS all did.

Now, whether or not the story is true, it's interesting to note that no-one including the OpenBSD project lead can quickly deny it. This, along with the Linux backdoors that have existed over time, lead me to question Torvalds' Law: many eyes make bugs shallow. Apparently it's possible to hide vulnerabilities in plain sight, too.

  • To defend linus somewhat, encryption at the programming level doesn't nearly as many eyes qualified to spot these issues.
    – Incognito
    Commented Dec 15, 2010 at 17:43
  • Picking a nit: Torvald's law was actually written by ESR ;-)
    – user185
    Commented Dec 15, 2010 at 18:27
  • +1+1+1, thank you, this is a perfect example of what I too have been saying. The Debian debacle a short while back is another... I'd proposed an ammendment to the eyeballs law: Many *qualified* eyes can make bugs shallow. While this may or may not be true (interest and motivation still have importance), this at least makes a little more sense.
    – AviD
    Commented Dec 15, 2010 at 19:41
  • @avid: yes, the debian "bug" was one I had in mind.
    – user185
    Commented Dec 15, 2010 at 23:52
  • 1
    @rox0r, but thats exactly the point - just cuz the code is available, or even if it was actually reviewed, this has little value when it comes to difficult esoterica. Most of security fits into that definition, btw...
    – AviD
    Commented Dec 16, 2010 at 21:38

The answer to your question is easy: if anyone hid nasty code in privileged subsystems, the wrong people could have arbitrary control over systems running the code.

But note that no evidence has been presented (and Perry should have a lot of that), and he offers no apologies.

For more info see

and the humorous conspiratorial comments on the responses by those accused: http://blog.scottlowe.org/2010/12/14/allegations-regarding-fbi-involvement-with-openbsd/ http://marc.info/?l=openbsd-tech&m=129244045916861&w=2


This doesn't really answer your question, but circa 2001 code may have had major changes in the last decade-ish so it's hard to say whether the code would still be there anyway (if it was there in the first place).

Somewhat closer to a useable answer: Graham has a listed a few. The next question is when did they start consuming that code? Before or after the introduction ofthe potential backdoor? If after, was there a code review done by the company? If so, did they find it? If so, did they fix it? If so, did they merge it back into the original project?


The best evidence, as I read it, is that the allegations of a backdoor in OpenBSD are so much hot air. It looks to me like a scurrilous and unjustified smear of OpenBSD, in an attempt to spread FUD (fear, uncertainty, and doubt).

In my view, Gregory Perry's allegations have little credibility at this point. I'll list some of the evidence against his allegations:

  • Perry provided no verifiable evidence in support of his allegation. He has not responded to requests for more information.
  • The claims in the letter are inherently not very credible. What government agency would give him a 10-year NDA that allows him to speak about the backdoor after 10 years pass? Hardly plausible.
  • An ongoing source code audit of OpenBSD has not found any evidence of a vulnerability at this point.
  • The person who is named in Perry's letter categorically denies the allegations. As he explains, he didn't even have access to the crypto code, nor did he write any of that code. Other OpenBSD developers have stepped up to vouch for him.
  • The OpenBSD software project had safeguards in place to defend against introduction of backdoors in the way that Gregory Perry describes, going so far as to ensure that all the crypto code for IPSEC is written by non-US citizens.
  • There are holes in Perry's story, particular, the timing. Perry had apparently left NETSEC before the backdoors were apparently developed, making it hard to understand how he would have gained knowledge of any backdoors if his story were true.

I think it is possible that NETSEC conducted internal studies to look into how to modify OpenBSD to add a backdoor for their own internal use, but there is no reason to believe that any backdoor was ever introduced into the official OpenBSD distribution.

Bottom line: I consider Perry's letter, which you quoted, a baseless smear against OpenBSD. OpenBSD has long been highly respected for its dedication to security. I suggest that you treat avoid re-distributing Perry's allegations.

Full disclosure: I have no association with OpenBSD or any of the parties in this little exchange. I have no financial interest in this matter. Heck, I don't even run OpenBSD on my servers. I just hate to see a good product subjected to baseless accusations.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .