[whatwg] Cryptographically strong random numbers

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


More information about the es-discuss mailing list