[HN Gopher] Entropy Attacks
___________________________________________________________________
Entropy Attacks
Author : todsacerdoti
Score : 81 points
Date : 2025-03-25 12:20 UTC (3 days ago)
(HTM) web link (blog.cr.yp.to)
(TXT) w3m dump (blog.cr.yp.to)
| commandersaki wrote:
| _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.
| jrexilius wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| hannob wrote:
| Technically correct, but the RNGs you're mentioning are
| essentially RNGs build on public key cryptography. And I
| don't think they're widely used, simply because they're
| slow and have no advantage over faster ones (the Dual EC
| stuff was, as far as I know, the only thing that was
| somewhat widely used, and, very obviously, nobody should
| be using that).
| zeven7 wrote:
| 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 wrote:
| 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.
| GTP wrote:
| > 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.
| hannob wrote:
| No, a Quantum RNG does not solve the issue that people
| use an API for insecure random numbers when they should
| use one for secure random numbers.
|
| Every OS already has a secure RNG API. That's a solved
| problem.
| commandersaki wrote:
| 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... .
| matthewdgreen wrote:
| 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/
| thebeardisred wrote:
| (2014).02.05
| Retr0id wrote:
| > 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.
| NoImmatureAdHom wrote:
| "If your system is compromised then you have a problem."
|
| ...well, yeah.
| 172327525 wrote:
| 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 wrote:
| 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.
| moralestapia wrote:
| Great article, makes sense, one can reduce entropy, of course.
| ex3ndr wrote:
| 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?
| _1tan wrote:
| https://web.archive.org/web/20220118154838/https://www.isg.r...
___________________________________________________________________
(page generated 2025-03-28 23:01 UTC)