4 ms·
Thanks, this is a great story to illustrate why there's almost never any advantage to using a TRNG over a cryptographic-strength PRNG. That's also why Linux rem
by jasperry 1y ago
Thanks, this is a great story to illustrate why there's almost never any advantage to using a TRNG over a cryptographic-strength PRNG. That's also why Linux removed the blocking RNG from the kernel; there was no attack model where it gave more security.
Of course, PRNGs should still be seeded with real entropy from the outside world, but even if that fails at some point, your PRNG will still be producing effectively unpredictable numbers for a long time.
- 7e 1y agoWith a PRNG the seed must be kept secret and non-reverse-engineerable. Isn't that a real disadvantage compared with a TRNG?
- jasperry 1y agoOnce a seed is fed to a PRNG, it can be deleted. But you still have a point, because the state of an OS PRNG can be saved and restored, for example when the machine sleeps, and a hacker could potentially access this to reproduce generated bits. But whenever the entropy pool is seeded with new entropy, any previous state values become useless.
- 7e 1y agoExactly, you need to protect the state of the PRNG and you need to ensure that the seed isn’t deterministic or easily reversed (time of day, 0, etc). That includes recovery from events and timing seen by the hypervisor. And some cloud VMs don’t have a non-deterministic entropy pool, or one safe from the hypervisor.