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).

Thanks,
Yaron

On 06/06/2011 09:44 PM, Aryeh Gregor wrote:

On Sat, Jun 4, 2011 at 1:52 AM, Yaron Sheffer <yaronf.ietf@gmail.com> 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
idea.]

Specifically I would propose (and I know the details can be debated
forever):

random(): returns a cryptographically-strong 32-bit random integer.
setRandom(r): mixes a user-supplied random integer r into the RNG internal
state.

This was discussed in February on whatwg:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030241.html

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
of randomness.