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