PRNG - currently available solutions aren't addressing many use cases

Steve Fink sphink at
Wed Dec 2 16:38:14 UTC 2015

On 12/01/2015 01:45 PM, David Bruant wrote:
> Le 01/12/2015 20:20, Michał Wadas a écrit :
>> As we all know, JavaScript as language lacks builtin randomness 
>> related utilities.
>> All we have is Math.random() and environment provided RNG - 
>> window.crypto in browser and crypto module in NodeJS.
>> Sadly, these APIs have serious disadvantages for many applications:
>> Math.random
>> - implementation dependant
>> - not seedable
>> - unknown entropy
>> - unknown cycle
>> (...)
> I'm surprised by the level of control you describe (knowing the cycle, 
> seeding, etc.). If you have all of this, then, your PRNG is just a 
> deterministic function. Why generating numbers which "look" random if 
> you want to control how they're generated?

I don't think the idea is that you need to know the cycle length, it's 
more that the spec does not currently mandate a minimum cycle length so 
implementations can and do implement Math.random in a way that produces 
cycle lengths much too short for some uses that might be expected to be 
reasonable. For example, if the generator internally uses independent 32 
bit values and doesn't mix them together before producing a 64 bit 
result, then the cycle length of each half of that result is at most 
2^32. You could record the whole set of them and perfectly predict the 
sequence with a couple of GB storage, much less if you can side-effect 
the generator you're after by drawing values from it yourself. Which 
perhaps doesn't matter, since you should be using a CPRNG if you're 
worried about prediction in the first place, but having a short cycle 
length for a subset of the bits will still bite you if you're masking 
off most of the bits (directly or indirectly). Having a birthday 
collision can really suck -- you thought you rented out the whole place 
for your party, only to find you have to share it with 3 other people. 
And they like *very* different music.

On the other hand, mandating a minimum cycle length may not help that, 
if the problem is with subsets of bits.

I'm not sure what "unknown entropy" means. I mean, in a way, if you seed 
it then there's zero entropy. Perhaps this refers to the capability of 
pulling from an external entropy source?

More information about the es-discuss mailing list