[whatwg] Cryptographically strong random numbers
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
> Glenn Maynard
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss