Re: Request for feedback: DOMCrypt API proposal - random number generation

On Mon, Jun 6, 2011 at 1:52 PM, Yaron Sheffer <> wrote:

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

What's the use case for this?  Are you concerned that the browser's PRNG
will not have sufficient randomness for your needs?

- James

> Thanks,
>     Yaron
> On 06/06/2011 09:44 PM, Aryeh Gregor wrote:
> On Sat, Jun 4, 2011 at 1:52 AM, Yaron Sheffer <> <> 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:
> 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.

Received on Monday, 6 June 2011 21:01:18 UTC