[whatwg] Cryptographically strong random numbers

[Adam Barth]

On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich <brendan at mozilla.org> wrote:

> On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:
>
> 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.
>
>
> I'm happy if the answer is "all OSes, mobile and desktop, provide enough
> high quality randomness". Looking for data if anyone has it.
>

As far as I can tell, /dev/urandom works great on all modern Unix-derived
operating systems (e.g., Mac, Linux, BSD, iOS, Android).  Windows since
Windows 2000 has CryptGenRandom:

http://msdn.microsoft.com/en-us/library/aa379942(v=vs.85).aspx

Are there other operating systems you're worried about?


> 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.
>
>
> Oh, who knows what any vendor will do under modern competitive pressure.
> Let's not assume :-/. My point is: to engage all the major browser vendors,
> we need a spec, not four-line (net of #ifdefs) patches.
>
> Here is another spec-worthy issue that IDL can't capture (and if we choose
> one way, can't even express): the #ifdefs raise the question (which David
> Wagner and I discussed briefly in private correspondence, and which I see
> came up on the whatwg list already) of whether it is better to provide a
> throwing stub when the OS randomness configury is not enabled, or better not
> to provide an object-detectible method at all?
>
> I'm inclined toward not providing a method that always throws. I've seen
> too much fool's gold mislead developers. Bugs and throwing stubs underlying
> detectible methods have led web developers to not just object-detect, but
> unit-test online! (See
> http://www.slideshare.net/jeresig/the-dom-is-a-mess-yahoo .) But testing
> detectible methods for correctness further bloats downloaded JS and slows
> first-run execution.
>

Ok.  We can change the API to be like that, if you like.  In WebKit,
USE(OS_RANDOMNESS) is defined on virtually every port.  There might be some
ports that aren't covered (e.g., BeOS) though.


> Ok.  I'll write up a spec later today.
>
>
> Thanks.
>
> On Mon, Feb 14, 2011 at 12:15 PM, Mark S. Miller <erights at google.com>
>  wrote:
>
>  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.
>
>
> There seems to be some spin here. What does "today" mean, and why the
> loaded "multi-month (year?) process" and "all-sing[ing]" etc. imputations to
> Ecma? I hope you are not describing how quickly you can hack on WebKit code,
> because while I can hack quickly on Mozilla code, that does not set the pace
> of a standard, never mind make a new feature available cross-browser to web
> developers.
>

Maybe I misunderstood TC39's intentions.  My understanding is that your
aspirations include a full-featured crypto library, e.g., at the level of
complexity of OpenSSL rather than at the complexity of arc4random.
 Certainly designing and implementing such a feature is a longer-term
prospect.


> While it indeed takes years to produce new Ecma (ISO) specs, we on TC39
> support early prototyping of harmonious proposals, so web developers can
> start using such candidate features. But for this to work we need a
> hand-shake on what is harmonious.
>
> If the idea is to promulgate a de-facto standard via Chrome and let other
> browsers reverse-engineer it, that can work, but it could backfire.
>

If that were my intention, we wouldn't be having this discussion.


> Extending the old window.crypto object we added ages ago at Netscape may be
> a good idea and a faster route to a high-quality cross-browser RBG. I won't
> argue about that. My objection here is to your choice of words and the way
> they might foreclose better cooperation among vendors: such an RBG API is
> not done "today", and it needs more than just one implementation to be a
> standard other browsers will implement.
>

I chose my words poorly.  What I was trying to communicate is that I'd love
to see ECMAScript grow a beautiful crypto library that included lots of
useful tools, including HMACs, stream ciphers, PRNGs, etc.  TC39 is in a
massively better position to do that work than the whatwg.  However, at this
point in time, adding a simple source of cryptographic random numbers to
window.crypto is much simpler proposition (e.g., on the order of one day of
work).

On Mon, Feb 14, 2011 at 12:56 PM, Mike Shaver <mike.shaver at gmail.com> wrote:

> On Fri, Feb 11, 2011 at 1:36 PM, Adam Barth <w3c at adambarth.com> wrote:
> > Regardless, the ability does not exist in JavaScriptCore.  If you'd
> > like to contribute a patch that makes it possible, I'm sure it would
> > be warmly received.
>
> That is surprising to me. Isn't it necessary in order to implement
> window.forms.<formname> and other dynamically-reflected properties?
>

Those sorts of APIs are implemented with what we call "custom" (read: slow)
bindings.

Adam