[csandreasen]

It's even more complicated than that - Juniper used Dual EC, and changed the Dual EC parameters, but ultimately the output of that PRNG was being used to seed a different PRNG (probably for speed purposes).

From your 2nd link:

ScreenOS does make use of the Dual_EC_DRBG standard, but is designed to not use Dual_EC_DRBG as its primary random number generator. ScreenOS uses it in a way that should not be vulnerable to the possible issue that has been brought to light. Instead of using the NIST recommended curve points it uses self-generated basis points and then takes the output as an input to FIPS/ANSI X.9.31 PRNG, which is the random number generator used in ScreenOS cryptographic operations.

Because of this, it's not entirely clear at this point that an attack would have been feasible even for an actor that had the P and Q used for Dual EC here[1].

[1] https://twitter.com/pwnallthethings/status/67837170536721203...

[matthewdgreen]

However: even in this setting, all it takes is a single unauthorized call to Dual EC and an exfiltration of 240 bits to obtain the values used in all subsequent re-seeding of the ANSI generator. We already know there is unauthorized code in ScreenOS based on Juniper's admission. So the next step is to determine whether something like this has occurred.

[csandreasen]

If code was added to leak the state of the PRNG, then whether or not Dual EC is used becomes a non-issue. The person who created the backdoor could leak the state regardless of which PRNG was used.