[whatwg] Cryptographically strong random numbers

[Adam Barth]

On Mon, Feb 14, 2011 at 11:56 AM, Brendan Eich <brendan at mozilla.org> wrote:

> On Feb 14, 2011, at 11:31 AM, Adam Barth wrote:
>
> What's non-interoperable about filling an ArrayBuffer with random bytes?
>  I'm not sure I understand your question.
>
> The question is what OSes fail to provide enough random bits these days.
>
> This may just be a sanity-checking step (my sanity, at least; I lived
> through the great entropy hunt of 1995;
> http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html [link courtesy
> dwagner]).
>

Somehow OpenSSL and NSS seem to solve that problem given that cryptographic
entropy is required to make HTTPS secure.  I'm certainly willing to believe
I've goofed it up, but I suspect it's not that much of a limitation these
days.

 However, I'm disinclined to wait on the basic best-effort PRNG for that to
> happen.
>
>
> What would you be waiting for? Ignoring Ecma, just adding code to WebKit
> doesn't make a cross-browser standard. Never mind Firefox (we'll do
> something soon enough to match). What about IE?
>

Given that we've missed IE9, we're talking about IE10 at the earliest.  If
history is a guide (which it might not be), that means we're talking about
something 2 years in the future.  If they're interested in supporting these
use cases, these APIs will (hopefully!) be long-stable by then.

It seems to me we (whatwg members, w3c members; browser vendors in general)
> need something more than IDL in the way of a spec.
>

Ok.  I'll write up a spec later today.

On Mon, Feb 14, 2011 at 12:01 PM, Shabsi Walfish <shabsi at google.com> wrote:

> On Mon, Feb 14, 2011 at 11:31 AM, Adam Barth <w3c at adambarth.com> wrote:
>
>> I'm not sure that's possible without either allowing the API to block for
>> arbitrary periods of time or to fail.  Assuming we want a non-blocking,
>> non-failing API, we can't make any guarantees about the quality of the
>> randomness.  In that sense, crypto.getRandomValues is "best effort."
>>
>
> I don't think its necessary to use "best effort" if you want something that
> is effectively non-blocking... what you need to do is preemptively gather a
> _small_ amount of real entropy on startup (say, 160 bits worth) and then use
> a cryptographic PRNG to generate whatever you need based on that seed... the
> PRNG would be pretty darn fast, so you wouldn't have to block forever after.
> Only the initial seeding needs to be done via a call to the OS that might
> block, and if that can be done asynchronously at startup time odds are good
> it will be a non-issue on most all platforms. Whatever you do, my advice is
> to combine entropy in the seed pool via XOR (assuming you do any entropy
> combining), since various combinations of append/prepend/etc. always lead to
> problems.
>

Right, but that approach does not provide any lower bounds on the quality of
the entropy.  If you keep running the PRNG, you'll eventually drain the
entropy pool.  It's an inescapable mathematical fact.  However, I agree that
it's a good best-effort design, and is precisely how arc4random works in Mac
OS X.


On Mon, Feb 14, 2011 at 12:15 PM, Mark S. Miller <erights at google.com> wrote:

> Before posting on this thread, please subscribe at <
> https://mail.mozilla.org/listinfo/es-discuss> to es-discuss. The
> es-discuss list drops posts by non-subscribers, and thus seems to have
> dropped posts by Adam Barth and Shabsi Walfish that were sent after
> es-discuss was added to the thread. Adam and Shabsi, could you please
> subscribe and re-post? Thanks.
>

Apologies.  I'm subscribed to es-discuss under a different email address.
 I'll fix that shortly.


> As has already been discussed, since these issues are general EcmaScript
> issues, applying not just in the browser but in many places JavaScript is
> run (e.g., nodejs), I suggest that this be the last message on this thread
> cross-posted to whatwg. Unless someone has a reason for retaining whatwg in
> the addressee list, I will drop it from all my further postings on this
> thread.
>

Actually, that is precisely what we're discussing.  My suggestion is that we
do both: browsers implement a simple DOM-based API today that handles the
basic arc4random-like use case and TC39 go through whatever multi-month
(year?) process it likes and spec out whatever all-sing, all-dance crypto
library it likes.

Adam