[whatwg] Cryptographically strong random numbers

[Adam Barth]

On Mon, Feb 14, 2011 at 8:31 AM, Mark S. Miller <erights at google.com> wrote:

> On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth <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.
>>
>
> The committee meets once every two months. Between meetings, we discuss
> things on es-discuss, so please do.
>
> What are the four lines of code?
>

http://trac.webkit.org/browser/trunk/Source/WebCore/page/Crypto.cpp

On Mon, Feb 14, 2011 at 8:40 AM, Boris Zbarsky <bzbarsky at mit.edu> 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.


Similarly, the WebKit implementation just passes the buck to the WTF layer,
which already knows how to fill a void* with n cryptographically random
bytes.  The implementation will be similarly trivial in most applications
that link with OpenSSL or NSS or that run on Mac, Linux, or Windows.

On Mon, Feb 14, 2011 at 10:05 AM, Brendan Eich <brendan at mozilla.org> wrote:

> 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?
>

What's non-interoperable about filling an ArrayBuffer with random bytes?
 I'm not sure I understand your question.

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

In this case, the API is several order of magnitude simpler than Date.  The
choices to make roughly boil down to the name of the function, which types
to support, and what sorts of exceptions to throw in which error cases.


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

I'm not sure that's possible without either allowing the API to block for
arbitrary periods of time or to fail.  Assuming we want a non-blocking,
non-failing API, we can't make any guarantees about the quality of the
randomness.  In that sense, crypto.getRandomValues is "best effort."

Obviously, a blocking API is in appropriate for the browser setting.
 There's certainly a place for failing randomness sources (e.g., analogous
to /dev/random versus /dev/urandom, although /dev/random is blocking rather
than failing).  The need just isn't as dire, in my view.  I'd certainly be
happy if ECMAScript came along in six months or a year with a nice
cryptographic library, including a variety of random generators (e.g.,
perhaps seedable, failing, and with algorithmic agility).  However, I'm
disinclined to wait on the basic best-effort PRNG for that to happen.


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

I added support for all the integer ArrayBuffer types, so getRandomBytes
isn't a particularly accurate name.

Adam