Random Number Generation with a Entropy pool versus Seed To give a little background I'm currently implementing a crypto library in JavaScript.

I have started porting across Linux's random number generator because its both publicly scrutinized, it is open-source, and is extremely well documented. After browsing around other implementations before settling on Linux's RNG, most of the other implementations like the Mersenne Twister and other PRNGs all use single byte seed values as their single source of entropy and to add more entropy you simply XOR the seed value with your "stream of entropy". Linux's RNG however uses a pool of entropy which consists of, as it sounds, a larger array of "seed" values in which all are considered to have a high amount of entropy. To add entropy, you simply XOR the entropy into the pool and mix it around with a few polynomials and hash it all to hide the internal state.

What I want to know is what are the benefits of using an entropy pool over a single byte seed value? It also sparks the question, considering Linux's RNG is used almost globally across the entire kernel and by every application requiring random data, is the "seed" or entropy source dependent on its use case? If only one application will be using the RNG at a time, is a single byte seed just as secure as a larger pool of entropy? Is the only reason Linux uses an entropy pool is to not give away any hints on internal seed state if other applications pull random data from it?

I guess what I'm trying to ask is what are the benefits of using a single byte seed value over an entropy pool, and is an entropy pool relevant for single user RNGs where only a single, trusted user uses the RNG?
What I want to know is what are the benefits of using an entropy pool over a single byte seed value? 


There are no benefits of an entropy pool. It's a  necessity.  If anything, it's a strong  indicator of a poor true random number generator (TRNG) and hints at the construction actually being a de facto pseudo random number generator (PRNG), which I believe /dev/random to be.

The golden rule of any TRNG is that H(in) >= H(out) where H is entropy. The following diagram illustrates the Linux random number generator's entropy pool.  



As the input events are totally irregular and of indeterminate frequency, H(in) cannot be calculated.  You can easily wait >60 seconds for a single random output byte to become available.  You mention that the Linux implementation is well documented.  Not for this point.  There is no quantitative assessment of input entropy that I can find in the literature.  The best is the report at the bottom, but that still accepts the developers' assessment of 1 bit of entropy/event.  It might well be far lower but as stated, irregular events cannot be given a rate.  No one has undertaken an accurate entropy measure of the jiffy events themselves. δ3s are not valid units of entropy.  Ergo the golden rule is not proven.

Thus the entropy pool acts as an accumulator and low pass filter to smooth the jiffies.  You will have had to implement this for yourself in your Javascript port.  Re iteratively hashing the pool is very much akin to the re permutations of a sponge construct during the squeeze phase, and thus another parallel with a PRNG.

TRNG are all about real entropy and it's accummulation.  Any port of /dev/random will have to address the capture of entropy from a machine, and as Javascript is more highly abstracted than the kernel, it will be harder. But a pool will be unavoidable.  You cannot easily re seed a generator's state byte by byte and bit by bit as irregular entropy events are detected.  Whether you implement a direct copy of /dev/random or some NIST CSPRNG, you'll need the pool to cheat. It's got nothing to do with the number of concurrent applications. You're confusing the entropy pool with a connection pool.

This question may be a trifle stale, but the answer is still relevant today for anyone developing a true random number generator.

Ref. François Goichon, Cédric Lauradoux, Guillaume Salagnac, Thibaut Vuillemin. Entropy transfers in the Linux Random Number Generator. [Research Report] RR-8060, 2012, pp.26.