[5] The security proof is therefore questionable and would be proven invalid if the x-logarithm problem is shown to be efficiently solvable.
However, RSA Security had been paid $10 million by NSA to use Dual_EC_DRBG as default, in a deal that Reuters describes as "handled by business leaders rather than pure technologists".
As the $10 million contract to get RSA Security to use Dual_EC_DRBG was described by Reuters as secret, the people involved in the process of accepting Dual_EC_DRBG into NIST SP 800-90A were presumably not made aware of this obvious conflict of interest.
[9] This might help explain how a random number generator later shown to be inferior to the alternatives (in addition to the back door) made it into the NIST SP 800-90A standard.
The potential for a backdoor in Dual_EC_DRBG had already been documented by Dan Shumow and Niels Ferguson in 2007,[10] but continued to be used in practice by companies such as RSA Security until the 2013 revelation.
Under random oracle model and assuming an oracle-independent entropy source:[4] CTR_DRBG has been shown to have a theoretical imperfection when used with certain parameters because cryptographers did not consider the block size of the cipher when designing this pseudorandom number generator.
[16] CTR_DRBG appears secure and indistinguishable from a true random source when AES is used as the underlying block cipher and 112 bits are taken from this pseudorandom number generator.
However, realizing the performance implications, the NIST recommends an "extended AES-CTR-DRBG interface" for its Post-Quantum Cryptography Project submissions.
This interface allows multiple sets of randomness to be generated without intervening erasure, only erasing when the user explicitly signals the end of requests.
[17] Woodage and Shumow (2019) provides a draft analyses of the situation mentioned by Bernstein, i.e. state leakage assuming large amounts of randomness (next) generated between re-keying (final).