With all these side channel attacks, I am suspecting that there may be a SPS theorem.
Given shared CPU, performance, and security, you can at best get 2 out of the three.
Cache Attacks on CTR_DRBG
11–20 of 21 posts
Re: Cache Attacks on CTR_DRBG
#12What 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?
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.
Re: Cache Attacks on CTR_DRBG
#13What 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?
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.
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.
Re: Cache Attacks on CTR_DRBG
#14Complete aside, but "black swan" is a terribly bad metaphor. 5 minutes drive and I can see hundreds of black swans, and not a single white one...
Re: Cache Attacks on CTR_DRBG
#15With all these side channel attacks, I am suspecting that there may be a SPS theorem. Given shared CPU, performance, and security, you can at best get 2 out of the three.
* without changing hiring and management practices at major chip designers and fabricators
Re: Cache Attacks on CTR_DRBG
#16Earlier quoted context omitted.
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).
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.
seed the whole system with live bitstream of a video feed trained on a wall full of lava lamps
Re: Cache Attacks on CTR_DRBG
#17Earlier quoted context omitted.
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.
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…
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 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..
Re: Cache Attacks on CTR_DRBG
#18What 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?
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...
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?
Re: Cache Attacks on CTR_DRBG
#19Complete aside, but "black swan" is a terribly bad metaphor. 5 minutes drive and I can see hundreds of black swans, and not a single white one...
Edit: not sure why the downvotes - because factually incorrect opinion or off-topic?I don't live far from here: https://www.christchurchdailyphoto.com/2011/09/29/black-swan...
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!
Re: Cache Attacks on CTR_DRBG
#20Earlier quoted context omitted.
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...
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?
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!