Hacker News Reader

Comment by EastLondonCoder | Hacker News Reader

Many years ago I used to work for a company in the gambling domain. There was a story going around from years before I joined that hardware TNRGs where used. And one day they failed. I can't remember precisely but heat was involved in one way or another and the failure mode they encountered was caused by overheating and repeatedly giving an endless series ones. A switch to PNRGs was promptly introduced.

View on HN

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.

With a PRNG the seed must be kept secret and non-reverse-engineerable. Isn't that a real disadvantage compared with a TRNG?

Once 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.

Exactly, 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.

Reply on news.ycombinator.com