[whatwg] Cryptographically strong random numbers

[Brendan Eich]

On Feb 14, 2011, at 8:40 AM, Boris Zbarsky wrote:

> On 2/14/11 11:31 AM, Mark S. Miller wrote:
>> On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth <w3c at adambarth.com
>> <mailto:w3c at adambarth.com>> wrote:
>> 
>>    That's a pretty long time horizon.  You're going to start discussing
>>    it in 2-4 months?  That seems a bit overwrought for what amounts to
>>    four lines of code.
> 
> For what it's worth, it's a lot more than 4 lines of code in Gecko, because we don't have an existing source of strong randomness in Spidermonkey.  It'd be about that much code in the DOM, where we could pass the buck to NSS, but for Spidermonkey it would take a good bit more work.

Not really. We use callback-style APIs to delegate such chores as l10n to the embedding, and the same can be done for randomness-hunting. It's just interfacing, or buck-passing -- but I'm still wondering what magical four lines of code provide useful lower bounds on bits of entropy in WebKit. Is this just non-interoperable delegation to the host OS?

Adam, I like moving fast (but beware, that's how JS and the DOM were created), but we need a cross-browser spec of some kind, even if we all add crypto.getRandomValues quickly. The original y2k-buggy, cloned-from-java.util.Date JS Date object of 1995 required a lot of work for ES1 to remove OS dependencies that made for interop hell.

For a core language standard, we would want some kind of minimum quality guarantee on the randomness.

Quick thought on the name: to avoid vagueness and the "why not wider int or even float element type" questions that have already come up, call the method getRandomBytes.

/be