On Feb 14, 2011, at 1:29 PM, Adam Barth wrote: > On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich <[email protected]> wrote: > On Feb 14, 2011, at 12:26 PM, Adam Barth wrote: >> On Mon, Feb 14, 2011 at 11:56 AM, Brendan Eich <[email protected]> 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. > > As far as I can tell, /dev/urandom works great on all modern Unix-derived > operating systems (e.g., Mac, Linux, BSD, iOS, Android). Windows since > Windows 2000 has CryptGenRandom: > > http://msdn.microsoft.com/en-us/library/aa379942(v=vs.85).aspx > > Are there other operating systems you're worried about?
Not for Mozilla (see below about BeOS). So as not to put up "stop energy", let me say this is great news, and I hope we're done. In parallel, hearing "all clear" from Ecma and W3C members who care about Symbian, Nokia's Linux-based stuff, anything not modern Windows (older mobile stuff), or the various proprietary real-time/embedded OSes would be helpful. > Ok. We can change the API to be like that, if you like. In WebKit, > USE(OS_RANDOMNESS) is defined on virtually every port. There might be some > ports that aren't covered (e.g., BeOS) though. Heh, Mozilla has a BeOS 'port, along with other OS/CPU targets that are not "tier 1" (where tier 1 has /dev/urandom or CryptGenRandom). I think the Amiga port died years ago ;-). But these can do without. The question is what the mechanics of "doing without" should be (runtime exception or no method detected). > 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. > > Maybe I misunderstood TC39's intentions. My understanding is that your > aspirations include a full-featured crypto library, e.g., at the level of > complexity of OpenSSL rather than at the complexity of arc4random. Certainly > designing and implementing such a feature is a longer-term prospect. Mark suggested such a program, and I like the idea (as you clearly do, cited below), but TC39 as a committee has not bought into it yet. Putting aside the idea of a larger crypto library TC39 task group, Mark did make a special case for the RBG in the core language, since Math.random is in the core language, cannot be removed, yet is also a footgun. This has been TC39's position: whatever we do with a separate task group for a crypto library, we have a Harmony agenda item, represented by that http://wiki.ecmascript.org/doku.php?id=strawman:random-er place-holder proposal. > 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. > > If that were my intention, we wouldn't be having this discussion. I think you're probably right that whatwg could get some crypto.getRandomValues spec together faster. For one, you've already done a bunch of work in that context! But I see the situation as fluid, no matter what standards body claims jurisdiction. If we prototype and test something successfully, then (with name changes if necessary) it could be put into either standard process. Neither process is "fast", since for IPR release the whatwg one still must flow into w3c. So my point is that nothing in the current standards bodies necessitates that an RBG proto-spec appears "today" in the whatwg context, vs. years from now in Ecma. Maybe we should have two APIs, but as David Bruant just argued, wouldn't it be better to have only one? The Chrome idea is not only a matter of your intentions. It could happen no matter what you intend, and that could be a good thing, too -- in the best case. I've promulgated de-facto standards, some of which did not suck. I did this during the IE monopoly era, to keep JS moving even though its standard was stagnating. However, not all of those de-facto standards were as good as I'd like, or as they would have been with some high-powered peer review and collaboration early in their lives. So again, I am less concerned with standards body end-games or even jurisdiction, and more concerned with getting the particulars of the spec "more right", sooner rather than later. With the (more-) right spec, and with good feedback and ongoing relations among the implementors and standards folks, I think you should implement in Chrome and drive a de-facto standard ahead of the de-jure one. So there! ;-) > 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. > > I chose my words poorly. What I was trying to communicate is that I'd love > to see ECMAScript grow a beautiful crypto library that included lots of > useful tools, including HMACs, stream ciphers, PRNGs, etc. TC39 is in a > massively better position to do that work than the whatwg. However, at this > point in time, adding a simple source of cryptographic random numbers to > window.crypto is much simpler proposition (e.g., on the order of one day of > work). Again this switches categories from standardization to implementation. It is a day's work to implement in Gecko as well as WebKit, and I claim at either the core-language or DOM window.crypto layer. That's all "easy" given the C++ or C RBG library functionality. What will take more than a day (see also Allen's post) is agreeing on API form and function in enough detail to gain traction with all the major browser implementors. But not too many days, I hope. /be
