[whatwg] Cryptographically strong random numbers
daw at cs.berkeley.edu
Wed Feb 16 11:05:19 PST 2011
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
I don't see anything here that would justify holding up or complicating
> 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
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.
More information about the es-discuss