[whatwg] Cryptographically strong random numbers
glenn at zewt.org
Mon Feb 14 17:01:41 PST 2011
On Mon, Feb 14, 2011 at 7:20 PM, Shabsi Walfish <shabsi at google.com> wrote:
> Hmm... if there is a guarantee that /dev/urandom was successfully seeded at
> some point in the past, then I'm happy with it. Is there such a guarantee? I
> don't see that documented anywhere, and I'm not sure how it would be
> provided. Since /dev/urandom never blocks, I'm assuming it will return
> something based mostly on weak entropy sources (like system time and/or or a
> very small number of real bits of entropy) in the event that the system
> hasn't really had a chance to seed the pool yet. I can live with not
> reliably refreshing the pool, but its pretty scary if you think about what
> happens when a user boots their phone up for the first time, etc. and there
> is just no entropy there yet.
There's no strict guarantee, since there's no API for /dev/urandom to refuse
to generate data if there's no entropy whatsoever. I suppose software can
read entropy_avail to make sure that there's at least something in there,
though I don't know if anything actually does that, and if that's something
entropy_avail is actually meant to be used for.
I don't think trying to expand this API for this--for example, a parameter
saying "throw an exception if the entropy buffer is empty"--would be
helpful. The cases that this happens are extremely narrow, and essentially
nonexistant on a running system; it would either never be used or result in
extremely poorly-tested code paths (both in UAs and in user code), and would
complicate things quite a lot (how long do you wait before trying again?).
(As an aside, I also don't know the state of hardware entropy generation on
modern hardware, which can likely generate entropy much more robustly than
the old hacks of mixing in interrupt timing and mouse movement, eliminating
the old problem of filling the entropy buffer from a first-time cold boot.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss