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