Sure, that would be much more efficient. And I agree with others on
that thread that the API should be non-blocking, non-failing, i.e.
akin to Linux /dev/urandom.
But my more important point was the second API: allow the code to
mix in any available entropy: keypresses, file contents, plain old
time, or externally obtained random bytes (http://www.random.org/). Maybe
this API should be called "updateRandom", because it does NOT
determine the full state of the PRNG, which should never be exposed.
I would say this could be an optional API (on Linux it simply
amounts to writing bytes *into* /dev/random, but I don't know if
it's implementable on Windows).
On 06/06/2011 09:44 PM, Aryeh Gregor wrote:
On Sat, Jun 4, 2011 at 1:52 AM, Yaron Sheffer <firstname.lastname@example.org> wrote:
However, I would like to propose one additional feature: a cryptographically
secure random number generator (CSRNG). This is a badly missed feature
today. [And just as I'm posting, I now see that Rich Tibbett beat me to this
Specifically I would propose (and I know the details can be debated
random(): returns a cryptographically-strong 32-bit random integer.
setRandom(r): mixes a user-supplied random integer r into the RNG internal
This was discussed in February on whatwg:
I didn't reread the whole thread, but my recollection is that people
preferred an API where you'd give it an ArrayBuffer and it would fill
it with random bytes. That way you can efficiently get large amounts