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