Cache Attacks on CTR_DRBG
security.cohney.info
security.cohney.info
Given shared CPU, performance, and security, you can at best get 2 out of the three.
BoringSSL implements CTR_DRBG with AES for example: https://boringssl.googlesource.com/boringssl/+/fed35d32245ee...
it's a source of a lot of online discussion as the compliant algorithms aren't the best available. here's to bureaucracy!
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.
To break the attack in this paper, you don't even need a hardware RNG; you just need hardware AES, like most modern platforms have (and like most mainstream operating systems use by default).
Suddenly after I read what you typed about RDRAND it clicked to me - you must never fully trust the hardware. Even if you TRUST the HW RNG, what is the harm of combining it into a broader RNG (assuming you know what you are doing).
Thanks for your time.
With hardware you have to always worry about some "physical" error, and if the hardware doesn't have sufficient diagnostics, you will never find out in software, because after whitening even a constant zero series from hardware looks indistinguishable from the failure-free output.
Intel itself ships expensive accelerator cards that have "zero software" in key seed generation capable of generating multiple gigabytes per second of random bits.
"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.
On second glance, it looks like NetBSD is only vulnerable if you aren't using hardware SHA-256, so still unlikely to affect anything but legacy. (Also, seriously NetBSD, CVS? It's 2019, even grandma uses a DVCS now)
Do you think it's possible to force software AES? That would be a cool attack. Probably wouldn't affect compiled code, but still..
I know active NetBSD developers who have no computers newer than about 2007, and have a core duo machine as their "build server".
Software AES is the only option for tons of folks who run NetBSD. Many of these folks run hardware on which their only real option is NetBSD - for them, and me, these platforms aren't legacy. They're just our computers.
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!