Entropy Attacks
32 comments
·March 25, 2025commandersaki
matthewdgreen
On the one hand this is true. Particularly the quantum stuff is mostly pointless. On the other hand, failure to incorporate fresh entropy into systems — turning them deterministic - is one of the rising crypto bug classes. The best solutions will mix the two.
Recent example: https://paulmillr.com/posts/deterministic-signatures/
jrexilius
Forgive my ignorance on this but does his assertion that a CSPRNG is all you need after an initial truly random seed, hold up against theoretical quantum attacks? If not, then I could see the need for very large/fast sources of entropy for OTP uses and such?
hannob
> Forgive my ignorance on this but does his assertion that a CSPRNG is all you need after an initial truly random seed, hold up against theoretical quantum attacks?
Yes, if you mean by "theoretical quantum attacks" the stuff we could run if we had a scalable quantum computer. Those impact public key crypto. They do nothing to impact the security of RNGs.
Retr0id
It's true that the stream-cipher and/or hash-based CSPRNG constructions that are commonly used are not broken by quantum computing.
CRQCs impact more than just public key crypto though, and there's more than one way to design a CSPRNG, so it's not true in the general case that they have "no" impact on RNGs.
I believe that Blum Blum Shub, Blum–Micali and Dual_EC_DRBG (backdoor aside) would also be broken by a CRQC.
matthewdgreen
Grover’s algorithm gives a square root speedup on many symmetric algorithms. This isn’t a disaster: it means you have to simply double your key (or hash digest or seed) sizes. But not every symmetric PRG out there is careful about this: some older ones may use 128 bit keys.
zeven7
Could you expand on that? I understand the idea from the quote, but I don't understand why you left your job. Was it because you assessed there wasn't a need for high throughput quantum random numbers? Or because you thought it was wasteful? Or something else?
The concern I would have with relying too much on a source key to derive other keys from would be if one of the keys is leaked, the others would also be exposed. I don't have an application in mind, but assume some could exist where that would be a concern. Maybe you could respond to that concern. I don't know what use cases your company would have been targeting.
hannob
His point was that he was working on a product that solves no actual problem.
Quantum RNGs are gimmicks that are sold as a solution to a security problem. But they don't solve any security problem. There are real security problems with RNGs, but none of them is solved by a Quantum RNG. They usually come down to implementation errors or not using a secure RNG.
kurikuri
No, they aren’t gimmicks. The advantage of a quantum-based entropy sources are that they are often much faster than other hardware based entropy source. They are called ‘quantum’ because they exploit randomness present in particle behaviors described by quantum physics (photon behavior on a beam splitter, etc.). Even ring oscillator based random number generators have quantum effects that contribute to its jitter (think shot noise, as an example), but the analysis of its randomness didn’t require quantum physics to describe it.
Quantum RNGs don’t exploit some ‘quantum computing’ property and are strictly limited to a different type of noise from the usual physical noise sources (ring oscillators, phase locked loops, etc.).
GTP
> not using a secure RNG.
Wouldn't a quantum RNG solve this issue? I'm aware that there are non-quantum ways to fix this problem, but in my mind quantum is one of the possible solutions, albeit one of the most expensives.
commandersaki
hannob aptly explained why I left my job, because Quantum RNG is a gimmick and doesn't solve any real problems. But to expand on that, it was heavily marketed with the idea that somehow we're living in a "entropy starved" world. We do a pretty good job of gathering entropy today from various sources such as mixing unique identifiers of hardware, CPU jitter, interrupt timing, RDRAND (which is a similar design to metastability of ring oscillators), etc. So the remark if you haven't managed to generate one secure 256-bit key then you have much bigger problems resonated heavily with me, and I realised there just isn't a need for gigabit speed TRNGs and the Quantum marketing is just scare tactics which my employer employed.
Also no crypto library or application is going to modify its entropy source to get its randomness from a TRNG device directly when it already has access to a high quality RNG via OS APIs/crypto libraries (for a good list of these check out https://randombytes.cr.yp.to/).
The concern I would have with relying too much on a source key to derive other keys from would be if one of the keys is leaked, the others would also be exposed
A modern RNG would implement fast key erasure which is what Jason Donenfeld did with random device in Linux. See https://blog.cr.yp.to/20170723-random.html and https://www.zx2c4.com/projects/linux-rng-5.17-5.18/inside-li... .
Retr0id
> There are also people asserting that it's important for RNGs to provide "prediction resistance" against attackers who, once upon a time, saw the entire RNG state.
At this point we regularly have microarchitectural side-channels that can (with varying speed and reliability) leak kernel memory. It's easy to say "if someone can read kernel memory it's game over", but imho it's better to harden against state compromise than to not.
172327525
I think this attack is less interesting than it sounds, given the specificity of the situation. IF you have a device which can read all the state/secrets on your machine AND the only write access it has to your machine is providing bits to use as an RNG seed, THEN (using this article) you can manipulate the output of the RNG, and exfil some data if you want.
I'm struggling to come up with a situation where this would happen.
sterlind
Low-level supply chain attacks. Like if the Supermicro story had panned out, or if the Intel RDRAND conspiracy theory were true, or you implanted some evil in an HSM.
eigenform
I'm not qualified to say anything about this stuff, but I get the impression this is just a tradeoff:
- Collect bits from many "points" in space, but a single "point" in time
- Collect bits from a single "point" in space, but many "points" in time
In either case, you are not eliminating the possibility that your "random" bits are subject to external influence, you're just moving it into some different domain.
thebeardisred
(2014).02.05
ex3ndr
The most interesting link is broken( does anyone knows how to find source for this link: https://www.isg.rhul.ac.uk/~sdg/igor-slides.pdf?
moralestapia
Great article, makes sense, one can reduce entropy, of course.
NoImmatureAdHom
"If your system is compromised then you have a problem."
...well, yeah.
On the other hand, there's no actual need for this huge pile of random numbers. If you've somehow managed to generate one secure 256-bit key then from that key you can derive all the "random" numbers you'll ever need for every cryptographic protocol—and you can do this derivation in a completely deterministic, auditable, testable way, as illustrated by EdDSA. (If you haven't managed to generate one secure 256-bit key then you have much bigger problems.)
This excerpt was the impetus to leave my job working for a company that makes a stupidly expensive high throughput hardware Quantum TRNG.