[whatwg] Cryptographically strong random numbers

Shabsi Walfish shabsi at google.com
Mon Feb 14 16:20:42 PST 2011

On Mon, Feb 14, 2011 at 4:15 PM, Glenn Maynard <glenn at zewt.org> wrote:

> On Mon, Feb 14, 2011 at 6:43 PM, Shabsi Walfish <shabsi at google.com> wrote:
>> OpenSSL is not exactly a reliable source of cryptographic best practices.
>> :) In any case, see here http://linux.die.net/man/4/urandom :
> No single implementation is; neither are Linux manpages.  The question is
> whether there are security issues when generating long-term keys from a
> secure PRNG (RC4, Yarrow, Fortuna) from an entropy pool that's been seeded
> but exhausted.  I suspect that question has been examined at great length by
> others in the past, so I doubt there's new ground for us to cover on this.
> It would be interesting if anyone knows of any competent analysis of this
> question (preferably in a form written for non-cryptographers).

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.


> In any case, an API which returns random data with a guarantee of entropy
> inherently must block, like /dev/random does.  That implies an asynchronous
> API, taking a callback which is called when the requested data is
> available.  Even if that's ultimately wanted, it would be a separate API.
> (Of course, if that API is created later, then it should be similar to this
> one--an asynchronous version of this synchronous API.  I can think of some
> minor speed bumps to making an async version of this API--you don't want to
> write to the array asynchronously, while other code is running--but nothing
> unreasonable.)
> --
> Glenn Maynard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110214/dc06aa78/attachment.html>

More information about the es-discuss mailing list