While I wish I was an uber-crypto-nerd, unfortunately I only have time to be an occasional crypto geek.
EDIT: Here's a start, from another front page HN article: "Dual-EC was an NSA effort to introduce a backdoored random number generator (RNG) that, given knowledge of a secret key, allowed an attacker to observe output from the RNG and then predict its future output."
However, having it in the standard (since removed) is perfect for fallback-like attacks or surreptitious changes (in the best case, your target has already implemented and deployed your exploit code and all you have to do is throw the switch to enable it!). That's what this is demonstrating (though some of the details are still speculative).
* Exception being those paid or required to do so by NSA.
The way I read this statement is that each device generates its own set of points. If this is the case, I don't see how it would work as a crypto backdoor.
If by "self-generated" they mean generated by Juniper once, well, thats fishy.
[0] http://kb.juniper.net/InfoCenter/index?page=content&id=KB282...
Edited to add: Upon further research, the latter possibility seems more likely.
Looks like they feed the output through a standard CPRNG. Assuming it's true, that pretty much breaks the DUAL_EC attack because you can't use the output of the final CPRNG to recover the DUAL_EC state.
Oddly, you can disable the Dual EC seeding with the flag 'one-stage-rng'. But not the other way around.
[1] http://csrc.nist.gov/groups/STM/cavp/documents/rng/931rngext...
While they wouldn't need to swap it out (since they can unlock standard Dual EC), that doesn't mean they wouldn't.
Assuming 1) that Dual EC was used here and 2) was inserted surreptitiously in a way that has a nonnegligible chance of discovery, it would make sense to rekey it since failing to do so would strongly attribute the attack to NSA (or someone willing to give up the passive backdoor opportunity in order to pin it on NSA).
The only case for NSA where using the old key would be best is if the use of standards-based Dual EC would pass scrutiny but a modified one would not. This depends on the details.
If switching Juniper to Dual EC required only calling a different function in Juniper's existing crypto library and/or detection was unlikely, standard Dual EC might be best. If the compromise added a full Dual EC implementation, then changing the constants is good (different magic constants don't significantly increase risk of detection for the large inserted code blob while significantly decreasing the risk of attribution).
No. It is not at all plausible that NSA backdoored ScreenOS in 2012 in order to rekey their backdoor.
I disagree that following the standard on that point and creating your own would be a smoking gun that the standard is malicious. Rather, it could be a smoking gun that this implementation was. If the tampering would likely be detected anyway, I'd argue it's better to avoid attribution.
It is certainly not the case that any part of the US Government acknowledged anything hinky about Dual EC in 2012. The notion that Dual EC was a cryptographic standards backdoor would have been one of the more closely guarded secrets in the entire government.
Virtually everything we now know about Dual EC is a result of the Snowden disclosures and the followup work people like Bernstein and Lange did in the wake of those disclosures. When analyzing stuff like this, it's important not to project knowledge we have now back before we had it.
However, in 2007, it wasn't just known that you could implement a backdoor, but how to do so. This of course means that any constants generated after this point could not be given the benefit of the doubt since anyone could launch this attack (and I think you'll grant me that all major intelligence services knew how to create and use a similar backdoor after 2007). And while USG did not acknowledge a backdoor, there was real, public doubt about the constants: Schneier's article in Wired was titled (notwithstanding Betteridge) "Did NSA put a Secret Backdoor in New Encryption Standard?"
Those in the standard were of unknown status, but even 2007 Schneier had the appropriately conservative cryptographer response and recommended "not to use Dual_EC_DRBG under any circumstances."
The pieces were there in 2012 for anyone that noticed a new Dual EC dependency being added, but I agree that the knowledge was not well-known enough (though it saddens me that a VPN manufacturer didn't know to avoid it 5 years later).
I still hold to the statement that rekeying Dual EC in 2012 is not a smoking gun on the standard, but more suggestive of an opportunistic attacker using the known mechanism for how to embed such a backdoor. If detected, it's obvious it's a backdoor, but that's not an indictment on the standard's constants (in fact, if you could otherwise attribute the attack to NSA, it's a tiny bit of evidence that either there is no standard backdoor or that USG don't want to use it in this case).
Here's a statement that I think we might disagree on: I believe that no one in 2012 that knew why the provenance of the constants could be a problem would have allowed Dual EC in the codebase in any form. This is why I believe the incremental chance of detection from changing the constants was small and why it'd be worth it to avoid attribution.
That said, I've stated my positions and see no need to continuing pressing legitimate points of disagreement. I just wanted to understand your position.
I conceded awhile ago that Dual EC was a crypto backdoor (before BULLRUN and the antics that were uncovered with RSA and with the European standards, I had suggested, as some other crypto people had, that Dual EC was too hamfisted and obvious to be a crypto backdoor).
But I've maintained since then that virtually nobody uses Dual EC, so its impact --- while clearly malign! --- is probably limited.
Nope. ScreenOS apparently (I'm not 100% sure, but that seems to be the way the wind is blowing) uses it to key VPN connections!
FULLY CONCEDED. The immediate known practical impact of Dual EC is, if that's true, enormous.
The weird thing about this particular backdoor is that the adversary seems to have modified the Dual EC parameters. Dual EC is an RNG with an embedded public key, where an adversary with the private key can "decrypt" the random bytes it generates to recover its state and rewind/fast forward it. This backdoor appears to swap out the public key, which is something NSA has no interest in doing.
My money is that this is the work of GCHQ, the world's most unhinged signals intelligence agency, and our partners in peace.