Cache Attacks on CTR_DRBG
security.cohney.info
Cache Attacks on CTR_DRBG
1–10 of 21 posts
Re: Cache Attacks on CTR_DRBG
#2flip a coin instead
Re: Cache Attacks on CTR_DRBG
#3What 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?
Re: Cache Attacks on CTR_DRBG
#4What 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...
Re: Cache Attacks on CTR_DRBG
#5What 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?
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.
Re: Cache Attacks on CTR_DRBG
#6What 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?
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…
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.
Re: Cache Attacks on CTR_DRBG
#7Earlier quoted context omitted.
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…
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-ve…
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).
Re: Cache Attacks on CTR_DRBG
#8Earlier quoted context omitted.
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-ve…
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.
Re: Cache Attacks on CTR_DRBG
#9Earlier quoted context omitted.
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…
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-ve…
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.
Re: Cache Attacks on CTR_DRBG
#10Earlier quoted context omitted.
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…
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-ve…
> 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.