# Using SHA3 as an entropy pool

Has any work been done on analyzing the SHA3 sponge construction for use as an entropy pool (e.g. /dev/random)?

All the use cases I've heard of consts of a sequence of input operations followed by a sequence of output operations where as an entropy pool would require security to be maintained for any sequence of intermingled input and output operations.

• Look up the duplex construction (essentially a different mode of operation for fixed-length permutation permutations like the Keccak-$f$). The Sponge home page has a bit of info about this (scroll down to almost the end), they also have a paper about a PRNG on their papers page. Sep 16 '13 at 16:51
• (My comment was not meant as a replacement for an answer ... if someone wants to write one, using the material linked in my comment, and other one, please go ahead. I'll not have the time to do so in the near future.) Sep 17 '13 at 18:39

As Paŭlo Ebermann already mentioned in his comments, SHA3 can indeed be used as a pseudo-random number generator.

The paper "Sponge-based pseudo-random number generators" talks about just that and it also describes a clean and efficient way to construct a re-seedable PRNG with a (Keccak) sponge function. What you'll get is a PRNG based on a cryptographic hash function… with the usual security implications.

For example: the paper explicitly states that you should reseed regularly with sufficient entropy to prevent an attacker from going backwards on the period of the PRNG (which is probably what you've been hearing about).

Related to proof of security of such a sponge-based PRNG construction, the paper states that the presented PRNG has the property of indifferentiability (which practically claims it is indifferent to an ideal PRNG), a resistance against state recovery (which is a result of it's indifferentiability), and that it passed the statistical tests proposed by NIST. This is the result of the fact that the sponge-based PRNG construction inherits the provable security properties of the sponge construction itself.

I would like to advise you to check on the paper yourself to grasp all the details; like learning how and when to re-seed the PRNG to prevent some potential attacks. It answers your question with ample detail.

• See Bernstein's post about Fast-key-erasure random-number generators; you don't actually need to reseed with external entropy to thwart an attacker who can't see all outputs. Sep 7 '17 at 23:18

SHA3 will have an entropy pool as large as its capacity. If you are trying to get computational security, this is great--that's what the Keccak PRNG paper shows you how to do. But if you are trying to collect a pool of entropy and dribble it out as requested (as with /dev/random), you have two issues:

1. The capacity limits the amount of entropy your pool retains.

2. It's not clear that you can use SHA3 to, say, put in 512 bits of entropy and then pull out 512 bits and expect to get full entropy from that.

Now, I think the notion of trying to conserve entropy in the /dev/random pool isn't terribly useful, so personally I think getting a PRNG with a security level of 256 bits (requiring a 512 bit capacity) is fine.