[periodontal]

> This backdoor appears to swap out the public key, which is something NSA has no interest in doing.

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).

[tptacek]

No. It is vitally important for NSA not to call attention to their crypto backdoor --- remember, this was inserted in 2012 --- and external tampering with the PKRNG in a VPN device is a smoking gun that Dual_EC is not a benign standard (still a plausible claim in 2012), but rather a surreptitious key escrow mechanism.

No. It is not at all plausible that NSA backdoored ScreenOS in 2012 in order to rekey their backdoor.

[periodontal]

The backdoor possibility was known in 2007 and the standard included a way to set your own constants (which no one used, true, but just because it was true for Dual EC in general).

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.

[tptacek]

The fact that you could use Dual EC to implement a backdoor was known in 2007, but it wasn't taken especially seriously; Schneier, for instance --- long a critic of elliptic curve crypto --- publicly cast doubt on it.

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.

[periodontal]

I agree that the oracle of hindsight can often lead us astray.

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.