- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 14 Feb 2011 13:29:43 -0800
On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich <brendan at mozilla.org> wrote: > 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. > 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? > 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. 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. > 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. > 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. > 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. > 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). On Mon, Feb 14, 2011 at 12:56 PM, Mike Shaver <mike.shaver at gmail.com> wrote: > On Fri, Feb 11, 2011 at 1:36 PM, Adam Barth <w3c at adambarth.com> wrote: > > Regardless, the ability does not exist in JavaScriptCore. If you'd > > like to contribute a patch that makes it possible, I'm sure it would > > be warmly received. > > That is surprising to me. Isn't it necessary in order to implement > window.forms.<formname> and other dynamically-reflected properties? > Those sorts of APIs are implemented with what we call "custom" (read: slow) bindings. Adam
Received on Monday, 14 February 2011 13:29:43 UTC