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

On Mon, Jun 6, 2011 at 1:52 PM, Yaron Sheffer <yaronf.ietf@gmail.com> 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 (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).
>

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 <yaronf.ietf@gmail.com> <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.
>
>