Given the revelations of recent years, we must assume that they exploited anything they could. Even if they didn't, that is still the prudent security assumption to make. Juniper speaks of a "knowledgeable attacker". Who is more knowledgeable an attacker than NSA? Perhaps Juniper employees? And how many are now working at/for NSA or some like agency?
This is the problem with secret organizations that are willing to spin stories and tell lies. The only prudent option is to fill all the blank spots in out knowledge with worst case scenarios. Maybe NSA had nothing to do with this, but there is nothing they or Juniper can say to substantiate that fact because they are no longer completely trustworthy. Math, code, these are not lies.
Beyond juniper, This is a growing worry amongst open source projects.
Can you find any open source projects that use it? Or ever have used it?
So we already knew that, what made the beans tilt at RWC is when they announced that the Dual EC introduction was accompanied with the increase of the nonce length during an IKE: from 20 to 32bytes. Which basically means "hey, now we have the Dual EC backdoor in place, _AND_ we have the full 30 bytes of output + 2 bytes of the next output for easy use of the backdoor".
> Virtually nobody believes the 2012 Dual EC backdoor was implanted by NSA
Doesn't mean it's a bad theory though, it could have been them, as well as a rogue employee or a remote french spy...
http://www.realworldcrypto.com/rwc2016/program/rwc16-shacham...
Shame there is no recording (and no paper).
paper is on the way
"When they introduced Dual EC in their code (Juniper), they also changed the nonce length from 20 bytes to 32 bytes (which is perfect for easy use of the Dual EC backdoor). Juniper did that! Not the hackers.
- they are aware, through their disclosure, that it is "exploitable"
- the new patch (17 dec 2015) removed the SSH backdoor and restored the Dual EC point.
A really good question from Tom Ritter: "how many bytes do you need to do the attack". Answer: truncated output of Dual EC is 30 bytes (instead of 32), so you need to bruteforce the 2 bytes. To narrow the search space, 2 bytes from the next output is practical and enough. So ideally 30 bytes and 2 bytes from a following output allows for easy use of the Dual EC backdoor."
When they reverted the "unauthorized" changes from 2012 (the backdoor in the news from a few weeks back), they were merely reverting to an older backdoor configuration.
The Reuters story isn't especially precise.
Dual EC, the construction, was designed by NSA (that's the "designed by NSA" referred to by the article.
NSA didn't write the code that appeared in ScreenOS in 2008 (or at least there's no evidence that they did).
Virtually nobody believes the 2012 Dual EC backdoor was implanted by NSA (Edward Snowden stated on Twitter that he believed NSA notified Juniper of that backdoor).
The big question now is how to attribute the 2008 backdoor (the original introduction of Dual EC to the platform). I lean towards believing it was sanctioned by NSA, because the changeset that introduced it included subtle tweaks to the rest of the system to make it easier to exploit, and those tweaks were --- I personally think --- not common knowledge among practitioners in 2008.
But there are arguments that it wasn't NSA; in particular, while the tweaks were subtle, the code introducing them is extremely hamfisted, easily reversed, and something of a dead giveaway about the nature of Dual EC, which, while known to be problematic in 2008, wasn't 100% believed to be the key escrow system it turns out to be.
If it's not NSA that introduced the original 2008 Dual EC backdoor, that's a devastating argument against policy officials who think we should design crypto backdoors: here's a backdoor concept designed in secret at NSA, turned against the US shortly after its introduction and undiscovered by the "good guys" for almost 10 years.