[whatwg] Cryptographically strong random numbers
daw at cs.berkeley.edu
Wed Feb 16 10:20:31 PST 2011
Shabsi Walfish writes:
> I don't disagree with this -- however, I would say the problem is that
> urandom may not return 160 "unguessable" bits to start with. Unguessable, of
> course, actually means "extremely difficult to predict with better than
> probability 1/2, conditioned on all previously observable information (such
> as approximate system time, process ids, etc.)". In any case, I was simply
> suggesting it would be nice to make available information about the quality
> of the entropy being returned by /dev/urandom, which is either going to be
> good (because the entropy pool was full) or _possibly_ not good (perhaps
> because the entropy pool hasn't ever filled up yet).
Well, personally I don't see any need, and I think it's an
unnecessary distraction. I don't see anything that should hold up
window.crypto.getRandom. I don't think this even rises to the level of
nice-to-have, but even if it did, I think the window.crypto.getRandom
effort should focus on must-haves, and not get hung up on nice-to-haves.
To explain why I don't think there's any reason to add a way to query
the quality of the pseudorandomness returned by /dev/urandom, I have to
geek out on cryptographer stuff. To all the non-cryptographers: please
ignore the crypto geeking out. The bottom line is, I think /dev/urandom
is fine, I think it's perfectly adequate for the job, and I see no basis
for delaying or complicating the window.crypto.getRandom API.
< cryptographer geek-out >
In my opinion, there's no need to check on the quality of /dev/urandom;
returning unguessable bits is its entire job and purpose for being.
There's a great deal of FUD and misunderstandings out there about
/dev/urandom, partly based upon a confusion between information-theoretic
security and computational-infeasibility security. It's not helped
by the fact that even the /dev/urandom man page lends support to the
Here's the issue. /dev/urandom is computationally secure. No, it's not
information-theoretically secure, but who cares? Information theoretic
security is irrelevant in practice; it's basically only a concern for
theoretical la-la land. (Do we reject all modern cryptography, and
insist that only the one-time pad is good enough for us? Of course not.
That'd be ridiculous.) /dev/urandom is a PRNG, not a RNG, and that's
plenty good enough for all the use cases we're talking about.
If you hear someone talk about a concern that the "entropy pool might
get drained", that's irrelevant to /dev/urandom. That'd only be relevant
if we were talking about information-theoretic security -- but we're not.
With a computationally-secure PRNG like /dev/urandom, once it's got 160
bits of unguessable entropy in its pool, it's good forever.
What about the concern that the entropy pool might never have gotten
enough entropy in the first place? I think that's exceedingly unlikely
on any system that will be running a browser. In every OS distribution
I've ever seen, there is a mechanism to ensure that entropy carries over
across boots: usually a shutdown-time script that dumps /dev/urandom's
entropy pool to disk, and a boot-time script that reads this saved
pool and adds it to the entropy pool. Thus, as long as the /dev/urandom
pool ever has enough entropy, it always will from there on, including
after every subsequent boot.
What about on first boot? Personally, I strongly expect that by the
interface, there will be sufficient entropy in the /dev/urandom pool.
If we're talking about a browser, then it's probably running on a
machine with peripherals (e.g., keyboard, mouse, touch screen, or
something along those lines).
In general, I suspect /dev/urandom is very unlikely to be the weakest
point in the system.
< / cryptographer geek-out >
So, coming back to the discussion: I don't see any barriers to
window.crypto.getRandom. As far as I can tell, modern OSes offer
enough support for getting randomness that it should not be difficult
for browsers to obtain the necessary randomness needed to implement
window.crypto.getRandom. And I think it's perfectly adequate to have a
simple interface that exposes only one function: get some crypto-quality
random bytes. I don't see a need for a more elaborate API.
More information about the es-discuss