Analysis of the Backdoored Backdoor(rpw.sh)
rpw.sh
Analysis of the Backdoored Backdoor
https://rpw.sh/blog/2015/12/21/the-backdoored-backdoor/
2 comments
So is there any plausible reason for using Dual_EC besides "the NSA is paying us off" and "we heard its security is based on the ECDLP so it maybe is harder to break"? From what I understand, it's slower and gives poorer randomness than most other well-established CSPRNGs.
Because, from here, it looks an awful lot like Juniper put their own backdoor in, and the hacker just changed it to let them use it instead. The use of Dual_EC alone, maybe, could be overlooked... but with an implementation bug that just so happens to reveal Dual_EC output directly... something's fishy.
Because, from here, it looks an awful lot like Juniper put their own backdoor in, and the hacker just changed it to let them use it instead. The use of Dual_EC alone, maybe, could be overlooked... but with an implementation bug that just so happens to reveal Dual_EC output directly... something's fishy.
Depends on what you mean by "any plausible reason".
There were cryptographers who could have given you a plausible reason to use Dual_EC --- all of them would have recommended against doing so, though.
But there's no practical reason.
There were cryptographers who could have given you a plausible reason to use Dual_EC --- all of them would have recommended against doing so, though.
But there's no practical reason.
Why the statement from Juniper, then? To try to CYA so they don't end up looking as shitty to the community as RSA did post-bribe?
EDIT: The conspiracy theorist in me would say "this is intentional, too." Changing a value to 31 from 32, or adding a single global assignment in a different function, wouldn't be caught on first review most likely, especially since where the '31' is, 31 is also used all over the code to refer to X9.31.
EDIT: The conspiracy theorist in me would say "this is intentional, too." Changing a value to 31 from 32, or adding a single global assignment in a different function, wouldn't be caught on first review most likely, especially since where the '31' is, 31 is also used all over the code to refer to X9.31.
Got a link to the 31/32 analysis?
I'm not sure there was a prior "31" but here's the code with the "32":
https://rpw.sh/blog/2015/12/21/the-backdoored-backdoor/
https://rpw.sh/blog/2015/12/21/the-backdoored-backdoor/
[deleted]
I think the most informative part of this writeup is this:
Niels Ferguson and Dan Shumow demonstrated that if the points are not randomly generated, but carefully chosen in advance, the security of Dual_EC DRBG can be subverted by the party doing the choosing; effectively backdooring the PRNG. Namely if one chooses P, Q such that Q=Pe holds for a value e that is kept secret, it will allow the party that generated said P, Q to recover the internal state of the PRNG from observed output in a computationally “cheap fashion” – hence instances of Dual_EC PRNG for which the provenance of the points P and Q is unknown are susceptible to having been backdoored.*
What assurance is there that the Q chosen by Juniper isn't subject to that type of backdoor vulernability? Why is Juniper using Dual_EC DRBG anyways? Aren't there other PRNG that are considered more robust?
Niels Ferguson and Dan Shumow demonstrated that if the points are not randomly generated, but carefully chosen in advance, the security of Dual_EC DRBG can be subverted by the party doing the choosing; effectively backdooring the PRNG. Namely if one chooses P, Q such that Q=Pe holds for a value e that is kept secret, it will allow the party that generated said P, Q to recover the internal state of the PRNG from observed output in a computationally “cheap fashion” – hence instances of Dual_EC PRNG for which the provenance of the points P and Q is unknown are susceptible to having been backdoored.*
What assurance is there that the Q chosen by Juniper isn't subject to that type of backdoor vulernability? Why is Juniper using Dual_EC DRBG anyways? Aren't there other PRNG that are considered more robust?
> Why is Juniper using Dual_EC DRBG anyways?
As a follow-on question: was NetScreen using Dual_EC_DRBG before Juniper bought them (and with it ScreenOS?) If so, it might be good to scrutinize the original NetScreen owners and where they are now (hint: They now run Fortinet and Palo Alto Networks. Are they at risk of interesting, compromised security choices, now, too?)
And you're right. Juniper could still have their own e, which renders the security pointless.
As a follow-on question: was NetScreen using Dual_EC_DRBG before Juniper bought them (and with it ScreenOS?) If so, it might be good to scrutinize the original NetScreen owners and where they are now (hint: They now run Fortinet and Palo Alto Networks. Are they at risk of interesting, compromised security choices, now, too?)
And you're right. Juniper could still have their own e, which renders the security pointless.
Yes, just about any PRNG is more robust than DUAL_EC. It's hard to implement correctly, its performance in software "is rotten"[0]. And even before the backdoor was discovered, the constants were suspect, and you can never get rid of that in your own implementation, as you have to generate those numbers then, then you are suspect.
[0]: http://blog.cryptographyengineering.com/2013/12/a-few-more-n...
[0]: http://blog.cryptographyengineering.com/2013/12/a-few-more-n...
https://twitter.com/_dvorak_/status/679109591708205056