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.i...@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. |
- Re: Request for feedback: DOMCrypt API proposal - random nu... Yaron Sheffer
- Re: Request for feedback: DOMCrypt API proposal - rand... Aryeh Gregor
- Re: Request for feedback: DOMCrypt API proposal - ... Yaron Sheffer
- Re: Request for feedback: DOMCrypt API proposa... James Robinson
- Re: Request for feedback: DOMCrypt API pro... Yaron Sheffer