- From: Mark S. Miller <erights@google.com>
- Date: Mon, 14 Feb 2011 12:15:25 -0800
Everyone, Before posting on this thread, please subscribe at < https://mail.mozilla.org/listinfo/es-discuss> to es-discuss. The es-discuss list drops posts by non-subscribers, and thus seems to have dropped posts by Adam Barth and Shabsi Walfish that were sent after es-discuss was added to the thread. Adam and Shabsi, could you please subscribe and re-post? Thanks. 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. On Mon, Feb 14, 2011 at 12:01 PM, Shabsi Walfish <shabsi at google.com> wrote: > > > On Mon, Feb 14, 2011 at 11:31 AM, Adam Barth <w3c at adambarth.com> wrote: > >> 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." >> > > I don't think its necessary to use "best effort" if you want something that > is effectively non-blocking... what you need to do is preemptively gather a > _small_ amount of real entropy on startup (say, 160 bits worth) and then use > a cryptographic PRNG to generate whatever you need based on that seed... the > PRNG would be pretty darn fast, so you wouldn't have to block forever after. > Only the initial seeding needs to be done via a call to the OS that might > block, and if that can be done asynchronously at startup time odds are good > it will be a non-issue on most all platforms. Whatever you do, my advice is > to combine entropy in the seed pool via XOR (assuming you do any entropy > combining), since various combinations of append/prepend/etc. always lead to > problems. > > Shabsi > > >> >> 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 >> >> > -- Cheers, --MarkM
Received on Monday, 14 February 2011 12:15:25 UTC