In particular: these attacks all appear to rely on classic cache-timing attacks against software AES. The "vulnerability" in these systems, then, isn't so much the CSPRNG construction so much as the use of a faulty vulnerable software AES primitive. Even FIPS-mode OpenSSL uses a hardware AES, and so the paper has to target an older version.
Slightly off-topic: Would it be near-impossible to have a hardware-level RNG generator that spits out bits at a sufficient enough rate to avoid software-based RNG schemes? My thought is to have a very-very-vetted hardware RNG, and use that as an anchor to build off of.
BoringSSL implements CTR_DRBG with AES for example: https://boringssl.googlesource.com/boringssl/+/fed35d32245ee...
"We found that NetBSD, FortiOS (a network device operating system) and OpenSSL FIPS implement CTR_DRBG in a fashion that is not side-channel resistant."
In compare with Dual_EC_DRBG, this PRNG is fast and most frequently used.
The legwork in the paper is interesting and worthwhile; they tracked down actual implementations and worked out the whole attack. But if you're going to go around gunning for something, it should be software AES, not CTR-DRBG.
I'm worried that people won't take that away, because "DRBG" is a weird NIST term that people might read too much into. But "DRBG" pretty much just means "CSPRNG". There's no relationship at all between Dual-EC and CTR.
Edit 2: looked up the metaphor, it really fails when I'm only surrounded by black swans. There are occasional white swans too - I have always presumed swans were migratory like plenty of the water foul over here!
Given shared CPU, performance, and security, you can at best get 2 out of the three.
