Usage and limitations of sponge functions for PRNG

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?

• I’m not seeing any thing there which criticizes the whitening algorithms method used by other TRNG. The criticism seems to bethat having any whitening on the TRNG device makes them more difficult to audit. This has nothing to do with the use of SHA-3, so can you clarify your question? Or at least point exactly to the statements you think are controversial? Jul 9, 2018 at 10:35
• Note that the sponge function has been used for extending the output of the hash by the authors itself, explicitly even in implementing the SHAKE functions, which are eXtendable Output Functions (XOFs). So that it is used for a RNG makes a lot of sense and was to be expected. Jul 9, 2018 at 13:03
• @rmalayter I added a link to the comparison table. It's not about criticising other's whitening algorithm and it's not about transparency. It is about comparing apples with oranges.
– jans
Jul 9, 2018 at 14:03
• @MaartenBodewes I clarified my question. Please have a look.
– jans
Jul 9, 2018 at 14:12
• Huh. I wonder what makes a \$35 dollar hardware cost deserve a green box and what makes something \$5 dollars more worthy of a red box. I wonder why 300kbit/s is green and 350 Kbit/s is red. Why is how fast a software RNG runs on the host CPU at all relevant? The advertised RNG outsources whitening to the host CPU. That speed is not a function of the hardware for sale. It's going to vary greatly based on the specs of your own (several hundred dollar) desktop computer. Why is free not in a green box? What miracle made the entire top row boxes all green? Jul 9, 2018 at 22:00

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.

• If someone can access getrandom they should use it instead of /dev/random or /dev/urandom. Let the value of "flags" be zero. If the flag GRND_RANDOM is not set then it will use the same source as urandom. When GRND_NONBLOCK is also not set then it will wait until /dev/urandom has enough entropy to be used safely. This makes the one use case of /dev/random unnecessary. Jul 9, 2018 at 21:14
• I know that I've championed AES RNGs, but isn't it possible to distinguish an AES-RNG after so many (lots & lots of) bits? Too many to worry about? Jul 10, 2018 at 0:10
• @PaulUszak Suppose your device can generate one 128-bit block every nanosecond, which is about 14 Gbit/sec of output. A birthday attack on AES-CTR at that rate would take approximately half a millennium. Jul 10, 2018 at 1:37

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.

• Upvote for fast-key-erasure CSPRNG, which I wasn't aware of.
– jans
Jul 10, 2018 at 19:00