# Why does anyone use elliptic curves for a CSPRNG?

I saw Martijn Grooten's talk on elliptic curves at BSides London this year, and it helped me understand how elliptic curve crypto works, especially in the case of Diffie-Hellman (ECDH). He also touched on the use of EC for random number generators (e.g. Dual_EC_DRBG) and why they can be flawed / backdoored.

This got me thinking: why do we even bother using EC for CSPRNGs? What drove us to even try? Surely block-cipher based CSPRNGs (e.g. AES-CTR) would be faster and more reliable, with no potential for "hidden number" backdoors? What is the key benefit that EC brings to the world of PRNGs, which outweighs their potential for weakness?

• AES as PRNG may fail. EC-CSPRNGs can't. They give you provably secure random numbers, assuming the ECDLP is intractable and your seed is unpredictable. The only way to attack those generators (like BBS) is to generate the key parameters yourself (like the reference points in DUAL_EC_DRBG) or to guess the seed or to break the reference problem. And this sense of provable security was what most people attracted (and that it was standard in bsafe...) – SEJPM Jun 5 '15 at 12:39
• @SOJPM AES-CTR was just an example - the point I was trying to make is that there other CSPRNG designs out there that don't have the "magic number" problem. That being said, your "provably secure" comment intrigues me - do you have a reference for a proof? I guess the proof relies upon the discrete log problem being known hard? – Polynomial Jun 5 '15 at 12:57
• In my comment AES-CTR also was only a "sample" for a non-provably secure CSPRNG. DUAL_EC_DRBG should have a similar prove to that BBS has but with EC-discrete logarithm problem (ECDLP) instead of FACTORING. – SEJPM Jun 5 '15 at 16:47
• Indeed DUAL_EC_DRBG seems to have such a proof, but because the instantiation was flawed (outputs too many bits / call) it's insecure with right informations. These links may interest you. – SEJPM Jun 5 '15 at 16:49
• As the person who gave the presentation that prompted the question, I can fully endorse Samuel Neves's comment. I should have mentioned that, apart from the backdoor, there are other good reasons not to use Dual_EC_DRBG (or ECC in general) in a PRNG. – Martijn Grooten Jun 6 '15 at 17:46

We, for the most part, don't bother with elliptic curve-based pseudorandom generators. DUAL_EC_DRBG was shoehorned into a NIST standard that also included a block cipher generator, CTR_DRBG, and two hash-based ones—Hash_DRBG and HMAC_DRBG—that are actually used in the field.
Number-theoretic generators, which include Blum-Blum-Shub, DUAL_EC_DRBG, and several others, tend to advertise provable security. What this means is that predicting the next bit reduces to solving a presumably hard problem, like integer factorization or the discrete logarithm problem. While this is appealing to mathematicians and theorists, this kind of generator tends to be very slow and hard to implement correctly, i.e., without leaking state information via a side-channel or buggy arithmetic.