Usage and limitations of sponge functions for PRNG

Question

This HRNG uses SHA3 as a sponge function (in its device driver) to inflate ots raw source output to many MByte/s. They compare this output rate to the output of other HRNG which don't use a sponge function. I'm wondering if this comparison is fair and brings me to the question to which extend a sponge function should be used to inflate RNG. The goal should be to get entropy suitable for cryptographic operations (e.g. key generation).

Edit: In other words, if a sponge function could be used to inflate 300 kByte/s to 500 MByte/s without reducing the entropy, why--talking Linux--to use /dev/random in favour of /dev/urandom at all?

Answer 1

The only reason to use /dev/random is to wait until the system has loaded entropy. If you have waited once, it is generally safe to use /dev/urandom. It has nothing whatsoever to do with speed of output. There is no reason to ever read more than a single byte from /dev/random in an application. Writing a benchmark that measures time to read long outputs from /dev/random is incompetence bordering on dishonesty. Writing an application like GnuPG that reads more than a single byte from /dev/random is incompetence bordering on malpractice. The only excuse is that the historical documentation of /dev/random was also incompetence bordering on voodoo.

In general, to be secure, any random number generator must have at least a minimum amount of entropy—say, 256 bits—after which point you can safely draw arbitrarily long outputs using whatever pseudorandom number generator you like. There are perfectly good stream-cipher-based PRNGs. There are perfectly good sponge-based PRNGs. It doesn't make much of a difference to security which one you choose as long as it provides an adequate security level.

There's no reason that the PRNG has to be on the same hardware IC as the entropy source. Indeed, it is better if you can scrutinize the raw output of the entropy source to confirm that it has the biases it is predicted to have before you wire it up to a PRNG. If the IC just stores a secret key $k$ and a count $c = 0, 1, 2, \dots$ of the number of requests made to it, and returns $\operatorname{AES-256}_k(c)$, you will have no way to distinguish that from a true entropy source. Of course, an adversary selling you these devices might write an elaborate simulator for the physical system it is advertised to have, but that won't be replicated if you fabricate your own instance of a free hardware design.

Answer 2

I'd say the comparison table is not a fair one, as it compares the Infinite Noise generator's throughput when feeding bits into a CSPRNG (Keccak) running on the host workstation and then running that CSPRNG as fast as the workstation allows. Other devices in the table achieve ~10 Mbit/sec speeds, but all of those devices in the table which had enough design documentation published on the web seem to advertise their throughput based on whitened output, but not on output expanded via a seeded CSPRNG on the host.

All of this is “much ado about nothing” however. A single 256-bit seed and a fast-key-erasure CSPRNG is all one should ever want in the real world. Don't create a persistent channel for attacker-controlled input. Or just use /dev/urandom.