On Wed, Feb 16, 2011 at 11:05 AM, David Wagner <d...@cs.berkeley.edu> wrote:
> Shabsi Walfish writes: > > I think the question is whether or not this can be done in general > without > > blocking -- if you block, you can definitely get crypto-quality random > > numbers, but otherwise its not clear... Personally, I think it makes > sense > > for the browser to have its own PRNG, and to get the seed from a > > high-quality (potentially blocking) source asynchronously, immediately > after > > startup (e.g., using /dev/random for Linux). That way, you can "block" on > > the JS level api call until the built-in PRNG has been properly seeded, > > since that blocking scenario should basically never happen in practice... > > and if it does, users would probably just attribute it to the normal > churn > > during browser startup anyway. > > I guess I don't see this as worth worrying about. > > /dev/urandom is a high-quality source. It does not block. > > Here's how to get crypto-quality random numbers without blocking: > > $ time dd if=/dev/urandom count=1 bs=20 status=noxfer of=/dev/null > 1+0 records in > 1+0 records out > [...] 0.00s user 0.00s system 0% cpu 0.001 total > > 160 bits of randomness obtained, without blocking. > > I don't see any reason why browsers would need to use /dev/random. > That feels to me like adding an unnecessary complication where none > is needed. > > I don't see anything here that would justify holding up or complicating > window.crypto.getRandom. > > > Maybe I'm just missing something here, but again, imagine a brand new > > Android phone that was just booted up for the first time (Android > basically > > runs Linux under the hood). Will the output from /dev/urandom (which is > not > > being specially seeded with accelerometer measurements, etc.) necessarily > be > > unpredictable, given the model of phone and approximate time? I'm not > > convinced. So just relying on /dev/urandom seems dangerous to me for that > > reason. > > The danger doesn't feel very dangerous to me. I think it would be > reasonable for browsers to not worry about this and let the Android OS > worry about that. > Thanks for the explanation David. I'm okay with pushing this off on some combination of the OS + JS interpreter, but just want it to be clear what the expectation should be for clients of the API. I agree with the way Oliver phrased it below -- the spec should simply demand that the returned values are cryptographically secure (cryptographically secure PRNG output is acceptable for that, there is certainly no need for info theoretic). If the implementations don't provide that guarantee its a bug in the OS or JS interpreter or both. If /dev/urandom is sufficient for that guarantee in practice, I'm perfectly happy with it. Mark's point about JS not running exclusively in the browser simply suggests that some JS interpreters on some platforms might need to do something like query entropy_avail at startup and wait for a while if need be, in order to provide this guarantee. I agree we don't need to expose entropy_avail in the API, given the behavior of /dev/urandom as you described here. Shabsi > > In more detail, I'd respond in five ways: > 1. This feels to me like an awfully obscure corner case to design > an entire API around. Put another way, the risk we're talking about > seems like a minor one to me. > 2. By the time the user launches the browser and starts interacting with > web sites, I would hope and expect that /dev/urandom would have > sufficient entropy, though I've never measured it and could be wrong. > 3. If for some reason it doesn't, then I'd say that's an Android bug, > not a browser bug. It's the OS's responsibility to ensure that > /dev/urandom's output is unpredictable. > 4. If you really care about this and want to classify it as a browser > bug, there are ways that browsers can deal with it (e.g., detect > the first boot condition and take special steps), but I think they'd > be adding unnecessary gyrations. It'd be up to each individual > browser whether they want to worry about this, but if they do, > there are steps they can take. > 5. The SSL protocol already requires the browser to generate > crypto-quality random numbers any time the browser accesses a > site over https. Whatever the browser is already doing to generate > random numbers for SSL, doing the same for window.crypto.getRandom > should be perfectly adequate. Browsers already have to solve > this problem; adding window.crypto.getRandom is not adding > a new burden on them. > > Overall, I think /dev/urandom is good enough for engineering purposes, > and I don't see that this warrants changing the API. Just my opinion. >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
