[whatwg] Cryptographically strong random numbers

[Adam Barth]

On Sun, Feb 13, 2011 at 11:35 AM, David Bruant
<bruant at enseirb-matmeca.fr> wrote:
> Le 05/02/2011 01:42, Adam Barth a écrit :
>> Several folks have asked for a cryptographically strong random number
>> generator in WebKit.  Our first approach was to make Math.random
>> cryptographically strong, but that approach has two major
>> disadvantages:
>>
>> 1) It's difficult for a web page to detect whether math.random is
>> actually cryptographically strong or whether it's a weak RNG.
>>
>> 2) Math.random is used in a number of popular JavaScript benchmarks.
>> Strengthening math.random to be cryptographically strong would slow
>> down these benchmarks.  Feel free to treat read this disadvantage as
>> "folks who don't care about cryptographic strength don't want to pay
>> the performance cost of cryptographic strength."
>>
>> Our second approach was to implement crypto.random, with the idea of
>> matching Firefox.  Unfortunately, Firefox does not appear to implement
>> crypto.random and instead just exposes a function that throws an
>> exception.  Additionally, crypto.random returns a string, which isn't
>> an ideal data type for randomness because we'd need to worry about
>> strange Unicode issues.
>>
>> Our third approach is to add a new cryptographically strong PRNG to
>> window.crypto (in the spirit of crypto.random) that return floating
>> point and integer random numbers:
>>
>> interface Crypto {
>>   Float32Array getRandomFloat32Array(in long length);
>>   Uint8Array getRandomUint8Array(in long length);
>> };
>>
>> These APIs use the ArrayBuffer types that already exist to service
>> APIs such as File and WebGL.  You can track the implementation of
>> these APIs via this WebKit bug:
>>
>> https://bugs.webkit.org/show_bug.cgi?id=22049
>>
>> Please let me know if you have any feedback.
> I am wondering if this topic is well-suited for the whatwg mailing-list.
> RNG has nothing to do with the web. It could be applied to the web or
> anything.
> This seems to be more of an ECMAScript issue. There is some drafty and
> incomplete work here :
> http://wiki.ecmascript.org/doku.php?id=strawman:random-er

Making Math.random cryptographically strong is a non-starter, as
discussed earlier in this thread.  Decoupling the Math.random state
for each global object is a good idea, but not related to making
cryptographically strong randomness available in the web platform.

> It might make sense to try to complete it with a proposal based on what
> have been said in that thread (especially the need of a different
> function than Math.random to not affect library using it with the
> overhead of cryptographically strong RNG).
> ES mailing-list: https://mail.mozilla.org/listinfo/es-discuss
>
> There are clear use cases, a couple of bugs related to the topic both at
> Mozilla and Webkit and some intention to work on having a
> cryptographically strong RNG in ECMAScript. Consequently, the process to
> have it standardized shouldn't be that different from what happens here.

It seems likely that window.crypto will continue to grow more quality
cryptographic APIs, not all of which will be appropriate at the
ECMAScript level.  For example, it's entirely likely we'll want to add
certificate generation and management APIs to window.crypto that
interact with the network stack (e.g., by making the generated
certificates function as HTTPS client certificates).

> It would also solve one of the problem cited in the WebKit bug which is
> that Web Workers have a limited access to the Window object features.
> However, if you add crypto to the ECMAScript global object, then your
> worker which has an ECMA(Java)Script context has an ECMA(Java)Script
> global object and since it's ECMAScript compliant (tell me if I'm wrong
> on that part), you have access to all ECMAScript features (String, Math,
> RegExp and the new crypto feature).

The WebWorker issue is independent of whether we define this API at
the DOM layer or at the ECMAScript layer.  For example, we could just
add the Crypto interface to WorkerContext to make this functionality
available to WebWorkers.

Adam