[whatwg] Cryptographically strong random numbers

David Bruant bruant at enseirb-matmeca.fr
Sun Feb 13 11:35:57 PST 2011

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
This seems to be more of an ECMAScript issue. There is some drafty and
incomplete work here :
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 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).



More information about the whatwg mailing list