On the Juniper backdoor

Many people seem to presume that the custom value of Q used by Juniper was done so that either they or some confederate could passively decrypt communications. The existence of a pre-intrustion bug that leaked the required bytes to allow this would seem to point in this direction as well.

But if someone was already making use of this backdoor, wouldn't they have quickly noticed if they lost access? And if this someone was Juniper (or someone allied with them) wouldn't they have been able to (perhaps silently) report and revert the change to regain access? It would seem that no one who knew the secret value objected to the change.

And now Juniper is fixing the problem by reverting to the original non-standard value, avoiding the presumed NSA-compromised recommended value. But what's special about that original value that they go out of their way to return to it? If their goal was truly security, why not hash something "provably" secure, as suggested in the article?

What's an interpretation of events where all these things make sense? The one that makes the most sense to me is to assume that the entity that made the "unsolicited" change to Q was the same as the one who knew the secret of the original, and they change was made because they wanted to restrict someone else's access. But this doesn't fit with the change back to the original, rather than to a new value.

Ripping out Dual EC DRBG entirely seems to be the only sensible choice here.

  The problem with cryptographic backdoors is not that they're the only way that
  an attacker can break intro our cryptographic systems. It's merely that _they're
  one of the best_. They take care of the hard work, the laying of plumbing and
  electrical wiring, so attackers can simply walk in and change the drapes.

Also, since these are part of the public-domain knowledge of the system, it is reasonable to expect that the values might even be built into hardware in the field, etc. and not easily changed. It might be much more feasible to revert to an earlier value if the original value was already stored somewhere.

The real problem with DualEC-PRNG is that if P and Q were somehow related, you wouldn't know this by looking at them and knowledge of the relationship would be restricted to the issuers (in the case of the "recommended" P and Q values, the NSA; in the case of Juniper, their own employees). The hidden relationship could be used to deduce the output of the generator and therefore deduce any keys based on the now-predictable values.

The ball is in Junipers court now: to prove they are merely incompetent and not outright malicious.

I spent a long time looking at all the options, the main issue with the open source ones is a lack of performance usually due to lack of asics/fpgas for encryption offloading.

When it came down to it, I went with Ubiquiti and their fork of VyOS called EdgeOS. Runners up router OS's were VyOS, PFSense, IPfire, routing engines being Quagga, XORP, and Bird Internet routing daemon.

The point is that open-source isn't an instant solution for these kinds of issues (code obfuscation, code review complexity, weakenesses in many-eyes theory) but it's still better than proprietary because at least you can fix it yourself if you please or at least someone else can.

I am a huge proponent of open-sourcing as much as possible, even given it's higher resource investment (hiring *nix-beards) because it gives a company freedom to be more agile than standard proprietary systems and their licensing-by-a-thousand-cuts and lock-in style.

Sometimes it doesn't make sense, and even as a FOSS proponent and a heavy GPLv3 supporter, I have to recognize sometimes that's not the best option either. I tend to still use Cisco on industrial controls, but it's mostly because of the service & support options, not because of Cisco's security. I just assume that just about every manufacturer based in the US has been NSL'ed and has backdoors in software & hardware... in the meantime, the solution for people like us is to push people like Juniper away from their old business model and force them into competing with FOSS. We can fix the software, but the hardware will be much more difficult. I have heard some interesting ideas on hardware checksumming lately though.

Just my two cents at least.

edit: Forgot to mention I am very fascinated by the networking features in DragonflyBSD, especially ipfw3, so if you haven't looked at it it's worth a peek. Also HAMMER2 is going to be awesome and is already on par with BTRFS and ZFS.

* Or maybe they had to use Dual EC because of government pressure but they changed the EC keypair to fuck with the NSA. NSA is not happy and changed it back.

* Or ...

In any case, what is clear is that a backdoored PRNG (Dual EC) was implemented behind a "fake" PRNG.

Someone knew that, and thus changed the EC keypair of the backdoored PRNG.

This is very shady.