[whatwg] Cryptographically strong random numbers

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
>

Received on Friday, 11 February 2011 03:38:25 UTC