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. 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
