[lacker]

What systems use this PRNG? While Googling around I found it surprisingly hard to figure out what algorithm is used for random number generation on e.g. Linux getrandom or the Chrome implementation of the Web Crypto API. Am I looking at the wrong layer of the stack?

[tptacek]

CTR_DRBG is basically the simplest reasonable CSPRNG, and a formalization/standardization of what other CSPRNGs do. As such, it's a good stationary "target" for research work. It's probably not a great idea to freak out about its presence in a design, since other designs will have similar flaws: if you have untrusted cotenant applications on the same hardware, side-channel attacks against your CSPRNG are going to be an issue.

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.

[GhettoMaestro]

As someone who has worked for a decade and a half with various asymmetric and symmetric ciphers and hashes in my field, I am embarrassed to admit that the inner-workings of a RNG/CSPRNG are still a bit cryptic to me.

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.

[tptacek]

You mean like RDRAND? They exist, but if they're built into COTS platforms, you have to trust then, and if they're not, you have to do extra work to assure the joinery and handle failure modes.

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).

[GhettoMaestro]

Yeah like RDRAND, but not compromised :P.

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.

[pg_is_a_butt]

seed the whole system with live bitstream of a video feed trained on a wall full of lava lamps

[Tomte]

Software has a very big advantage here: only systematic failures possible, no random failures.

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.

[baybal2]

> 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?

Intel itself ships expensive accelerator cards that have "zero software" in key seed generation capable of generating multiple gigabytes per second of random bits.

[f2f]

anything that is FIPS compliant will use one of the mandated DRBGs, there are two others besides CTR_DRBG.

BoringSSL implements CTR_DRBG with AES for example: https://boringssl.googlesource.com/boringssl/+/fed35d32245ee...

[baby]

What I don’t understand about this is, if you’re FIPS compliant you can’t just use the PRNG of /dev/urandom? You must use a FIPS as well?

[f2f]

yes. fips compliance says "use what we tell you to use. want government contracts? be fips compliant."

it's a source of a lot of online discussion as the compliant algorithms aren't the best available. here's to bureaucracy!

[MrXOR]

From the above link:

"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.

[tptacek]

Again, by "not side-channel resistant", they appear to mean "implemented with software AES that is already known to be vulnerable to side-channel attacks". The attack here is not especially tied to the CSPRNG construction; it's a straightforward application of an already known attack.

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.

[peterwwillis]

What's bizarre is that anyone would use software AES. AES-NI has been around over 10 years, and tons of other platforms have instructions or hardware acceleration, plus lots of libraries implement it. It's crazy that NetBSD is vulnerable, but I can't see how OpenSSL FIPS is vulnerable unless it's versions <1.0.1?

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..

[goshhhy]

my SGI Indy, 486dx pc, Motorola Starmax, iBook G3 Clamshell, and iMac G3 all run NetBSD and have no hardware accelerated AES.

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.