PRNG taking advantage of very large seed

Question

Can anyone suggest a good (CS)PRNG algorithm that takes advantage of having a very large (ideally arbitrarily large) seed? I'd like to use several kilobytes, perhaps several hundred kilobytes, of random data to generate up to a few dozen megabytes of PRNG output. The PRNG algorithms I'm aware of only take relatively small seeds: I'd like to make the most of the random input data I have.

Answer 1

The PRNG proposed by Barak and Halevi should be able to meet your needs and provide sufficient security.

Their PRNG has an API of next and refresh. refresh takes an arbitrarily long string and uses it to update the internal state of the PRNG. next returns some number of random bytes (if more is needed, one can simply call next in succession).

They prove some very nice properties of their PRNG (which together define robustness of a PRNG), and give a concrete implementation.

The entire paper is definitely worth a read.

Answer 2

What you are doing sounds a lot like what the /dev/random and /dev/urandom or the PRNGD on many systems already do: those systems take an arbitrary large sequence of numbers (from a true hardware random number generator if available, or else from environmental noise such as keystroke timing) and feed it into a CSPRNG; the output is made available via /dev/random and /dev/urandom .

Perhaps you could somehow extract the source code implementation of any one of those systems, and make a user-level variant that, rather than getting input from environmental sources, only gets input from your large seed.

• FreeBSD and AIX implement /dev/random using the Yarrow algorithm
• OpenBSD implements /dev/random using an algorithm based on RC4 (is this the same as ISAAC ?)
• Fortuna
• My understanding is that many other CSPRNG implementations have a way to feed in more bits of entropy.

Answer 3

Don't bother. Take any cryptographically secure CSPRNG. Feed it a random key (make sure the key length is at least 128 bits). You're done. Once the key length is 128 bits or so, any additional length is pointless overkill.

If you have a thousand-bit seed, just hash it first to get it down to be the right size of the key of your CSPRNG -- but make sure you have at least that much entropy in the seed. Or, better yet, simply generate your key using a secure pseudorandom number generator, like /dev/urandom or CryptGenRandom.

Answer 4

This is probably obvious now (more obvious, at least, than before Keccak won the SHA-3 competition) but what is being asked for here sounds an awful lot like a sponge function. Or a sponge function in duplex mode, if the finite state is such a serious concern.