[whatwg] Cryptographically strong random numbers

[Adam Barth]

Just to followup on this thread, I've landed this feature in WebKit.
I'm not sure whether it made it into tonight's nightly, but it should
be in a nightly shortly.  The IDL for the API is as follows:

interface Crypto {
 void getRandomValues(in ArrayBufferView array) raises(DOMException);
};

If the ArrayBufferView isn't a Uint8Array or if the user agent is
unable to obtain "true" randomness from the OS, getRandomValues throws
an exception (VALIDATION_ERR in the former case and NOT_SUPPORTED_ERR
in the latter case).

If the function doesn't throw an exception, the array is filled with
bytes obtained from a cryptographically strong PRNG seeded with "true"
randomness from the operating system.  Internally, WebKit uses RC4 as
the PRNG, but any cryptographically strong PRNG should work fine.

If there's interest, I can write up the above as a more formal
specification, but that seems like a bit of overkill given the
simplicity of the API.  Thanks for all your feedback.  It was quite
helpful.

Adam


On Fri, Feb 4, 2011 at 4:42 PM, Adam Barth <w3c at adambarth.com> wrote:
> 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.
>
> Thanks,
> Adam
>