[whatwg] Cryptographically strong random numbers

[Mark S. Miller]

Everyone,

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.

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.


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:
>
>> On Mon, Feb 14, 2011 at 8:31 AM, Mark S. Miller <erights at google.com>wrote:
>>
>>> On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth <w3c at adambarth.com> wrote:
>>>
>>>> That's a pretty long time horizon.  You're going to start discussing
>>>> it in 2-4 months?  That seems a bit overwrought for what amounts to
>>>> four lines of code.
>>>>
>>>
>>> The committee meets once every two months. Between meetings, we discuss
>>> things on es-discuss, so please do.
>>>
>>> What are the four lines of code?
>>>
>>
>> http://trac.webkit.org/browser/trunk/Source/WebCore/page/Crypto.cpp
>>
>> On Mon, Feb 14, 2011 at 8:40 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>>
>>>  On 2/14/11 11:31 AM, Mark S. Miller wrote:
>>>
>>>>  On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth <w3c at adambarth.com
>>>> <mailto:w3c at adambarth.com>> wrote:
>>>>
>>>>    That's a pretty long time horizon.  You're going to start discussing
>>>>    it in 2-4 months?  That seems a bit overwrought for what amounts to
>>>>    four lines of code.
>>>>
>>>
>>> For what it's worth, it's a lot more than 4 lines of code in Gecko,
>>> because we don't have an existing source of strong randomness in
>>> Spidermonkey.  It'd be about that much code in the DOM, where we could pass
>>> the buck to NSS, but for Spidermonkey it would take a good bit more work.
>>>
>>
>> Similarly, the WebKit implementation just passes the buck to the WTF
>> layer, which already knows how to fill a void* with n cryptographically
>> random bytes.  The implementation will be similarly trivial in most
>> applications that link with OpenSSL or NSS or that run on Mac, Linux, or
>> Windows.
>>
>> On Mon, Feb 14, 2011 at 10:05 AM, Brendan Eich <brendan at mozilla.org>
>>  wrote:
>>
>>> On Feb 14, 2011, at 8:40 AM, Boris Zbarsky wrote:
>>> > On 2/14/11 11:31 AM, Mark S. Miller wrote:
>>> >> On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth <w3c at adambarth.com
>>>  >> <mailto:w3c at adambarth.com>> wrote:
>>> >>
>>> >>    That's a pretty long time horizon.  You're going to start
>>> discussing
>>> >>    it in 2-4 months?  That seems a bit overwrought for what amounts to
>>> >>    four lines of code.
>>> >
>>> > For what it's worth, it's a lot more than 4 lines of code in Gecko,
>>> because we don't have an existing source of strong randomness in
>>> Spidermonkey.  It'd be about that much code in the DOM, where we could pass
>>> the buck to NSS, but for Spidermonkey it would take a good bit more work.
>>>
>>> Not really. We use callback-style APIs to delegate such chores as l10n to
>>> the embedding, and the same can be done for randomness-hunting. It's just
>>> interfacing, or buck-passing -- but I'm still wondering what magical four
>>> lines of code provide useful lower bounds on bits of entropy in WebKit. Is
>>> this just non-interoperable delegation to the host OS?
>>>
>>
>> What's non-interoperable about filling an ArrayBuffer with random bytes?
>>  I'm not sure I understand your question.
>>
>> Adam, I like moving fast (but beware, that's how JS and the DOM were
>>> created), but we need a cross-browser spec of some kind, even if we all add
>>> crypto.getRandomValues quickly. The original y2k-buggy,
>>> cloned-from-java.util.Date JS Date object of 1995 required a lot of work for
>>> ES1 to remove OS dependencies that made for interop hell.
>>>
>>
>> In this case, the API is several order of magnitude simpler than Date.
>>  The choices to make roughly boil down to the name of the function, which
>> types to support, and what sorts of exceptions to throw in which error
>> cases.
>>
>>
>>> For a core language standard, we would want some kind of minimum quality
>>> guarantee on the randomness.
>>>
>>
>> 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.
>
> Shabsi
>
>
>>
>> Obviously, a blocking API is in appropriate for the browser setting.
>>  There's certainly a place for failing randomness sources (e.g., analogous
>> to /dev/random versus /dev/urandom, although /dev/random is blocking rather
>> than failing).  The need just isn't as dire, in my view.  I'd certainly be
>> happy if ECMAScript came along in six months or a year with a nice
>> cryptographic library, including a variety of random generators (e.g.,
>> perhaps seedable, failing, and with algorithmic agility).  However, I'm
>> disinclined to wait on the basic best-effort PRNG for that to happen.
>>
>>
>>> Quick thought on the name: to avoid vagueness and the "why not wider int
>>> or even float element type" questions that have already come up, call the
>>> method getRandomBytes.
>>>
>>
>> I added support for all the integer ArrayBuffer types, so getRandomBytes
>> isn't a particularly accurate name.
>>
>> Adam
>>
>>
>


-- 
    Cheers,
    --MarkM