[whatwg] Cryptographically strong random numbers

[Brendan Eich]

On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:

> On Mon, Feb 14, 2011 at 11:56 AM, Brendan Eich <brendan at mozilla.org> wrote:
> On Feb 14, 2011, at 11:31 AM, Adam Barth wrote:
>> What's non-interoperable about filling an ArrayBuffer with random bytes?  I'm not sure I understand your question.
> The question is what OSes fail to provide enough random bits these days.
> 
> This may just be a sanity-checking step (my sanity, at least; I lived through the great entropy hunt of 1995; http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html [link courtesy dwagner]).
> 
> Somehow OpenSSL and NSS seem to solve that problem given that cryptographic entropy is required to make HTTPS secure.  I'm certainly willing to believe I've goofed it up, but I suspect it's not that much of a limitation these days.

I'm happy if the answer is "all OSes, mobile and desktop, provide enough high quality randomness". Looking for data if anyone has it.


>> However, I'm disinclined to wait on the basic best-effort PRNG for that to happen.
> 
> What would you be waiting for? Ignoring Ecma, just adding code to WebKit doesn't make a cross-browser standard. Never mind Firefox (we'll do something soon enough to match). What about IE?
> 
> Given that we've missed IE9, we're talking about IE10 at the earliest.  If history is a guide (which it might not be), that means we're talking about something 2 years in the future.

Oh, who knows what any vendor will do under modern competitive pressure. Let's not assume :-/. My point is: to engage all the major browser vendors, we need a spec, not four-line (net of #ifdefs) patches.

Here is another spec-worthy issue that IDL can't capture (and if we choose one way, can't even express): the #ifdefs raise the question (which David Wagner and I discussed briefly in private correspondence, and which I see came up on the whatwg list already) of whether it is better to provide a throwing stub when the OS randomness configury is not enabled, or better not to provide an object-detectible method at all?

I'm inclined toward not providing a method that always throws. I've seen too much fool's gold mislead developers. Bugs and throwing stubs underlying detectible methods have led web developers to not just object-detect, but unit-test online! (See http://www.slideshare.net/jeresig/the-dom-is-a-mess-yahoo .) But testing detectible methods for correctness further bloats downloaded JS and slows first-run execution.


> Ok.  I'll write up a spec later today.

Thanks.


> On Mon, Feb 14, 2011 at 12:15 PM, Mark S. Miller <erights at google.com> wrote:
> As has already been discussed, since these issues are general EcmaScript issues, applying not just in the browser but in many places JavaScript is run (e.g., nodejs), I suggest that this be the last message on this thread cross-posted to whatwg. Unless someone has a reason for retaining whatwg in the addressee list, I will drop it from all my further postings on this thread.
> 
> Actually, that is precisely what we're discussing.  My suggestion is that we do both: browsers implement a simple DOM-based API today that handles the basic arc4random-like use case and TC39 go through whatever multi-month (year?) process it likes and spec out whatever all-sing, all-dance crypto library it likes.

There seems to be some spin here. What does "today" mean, and why the loaded "multi-month (year?) process" and "all-sing[ing]" etc. imputations to Ecma? I hope you are not describing how quickly you can hack on WebKit code, because while I can hack quickly on Mozilla code, that does not set the pace of a standard, never mind make a new feature available cross-browser to web developers.

While it indeed takes years to produce new Ecma (ISO) specs, we on TC39 support early prototyping of harmonious proposals, so web developers can start using such candidate features. But for this to work we need a hand-shake on what is harmonious.

If the idea is to promulgate a de-facto standard via Chrome and let other browsers reverse-engineer it, that can work, but it could backfire.

Extending the old window.crypto object we added ages ago at Netscape may be a good idea and a faster route to a high-quality cross-browser RBG. I won't argue about that. My objection here is to your choice of words and the way they might foreclose better cooperation among vendors: such an RBG API is not done "today", and it needs more than just one implementation to be a standard other browsers will implement.

/be