Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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?

share|improve this question
    
Your first paragraph is a bit fuzzy. If you need a cryptographically secure pseudo random number generator, it is because you need cryptographically secure pseudo random numbers, and whatever that reason might be, it is cryptographic by definition. If not, you might need a PRNG, but not necessarily a CSPRNG, and should probably ask elsewhere. –  Henrick Hellström Dec 30 '13 at 3:16
    
@HenrickHellström The difference between a CSPRNG and a PRNG is simply that one can be predicted and one cannot. I may want to make a poker game where I do not wish to have the randomness predicted so a CSPRNG would be ideal. –  jduncanator Dec 30 '13 at 4:44
    
There is window.crypto.getRandomBytes. You may already have looked at this and decided not to use it (incompatibility), etc., but for anyone reading the post not aware, that's an honest-to-goodness built-in CSPRNG implemented by newer browsers. Also, there is the SJCL which has Fortuna already implemented. None of this affects the validity of your question, but I wanted to give already-built solutions. –  Reid Dec 30 '13 at 4:50
    
@Reid Thanks. I do already have this implemented but considering its really new I am deciding to back the RNG with something slightly better than Math.random as a fallback. I did look at SJCL but as I've already started porting, I will simply continue porting it. This was more of a side question :) –  jduncanator Dec 30 '13 at 4:52
1  
Instead of implementing Linux's RNG in JavaScript, I would implement one of CTR_DRBG, Hash_DRBG or HMAC_DRBG from NIST Special Publication 800-90A. These fulfill requirements of CSPRNG, unlike e.g. Mersenne Twister, which you shall avoid in cryptographic uses. One great aspect of NIST's RNG's is that they provide test vectors to ensure implementation is correct. A RNG like Linux's but in JS will be significantly different impl than Linux's and it does not have any test vectors anywhere making it hard to ensure correctness. –  user4982 Dec 30 '13 at 14:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.