[whatwg] Cryptographically strong random numbers

[Adam Barth]

On Fri, Feb 11, 2011 at 4:32 AM, Glenn Maynard <glenn at zewt.org> wrote:
> On Fri, Feb 11, 2011 at 6:38 AM, Adam Barth <w3c at adambarth.com> wrote:
>> 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).
>
> Rather than raising NOT_SUPPORTED_ERR, would it be better to follow the
> example from other specs: to omit the function entirely if the feature is
> disabled?  (Specifically, "When support for a feature is disabled (e.g. as
> an emergency measure to mitigate a security problem, or to aid in
> development, or for performance reasons), user agents must act as if they
> had no support for the feature whatsoever, and as if the feature was not
> mentioned in this specification.")
>
> That's nicer for checking whether the function exists to check support.
> Otherwise, you have to make a dummy call to check support.  It also means
> you only need to check support in one way--since you'll need to check
> whether the function exists anyway.

In some cases, it's not possible to determine whether we'll be able to
get OS randomness until runtime.  For example, on Linux, if we don't
have permission to read /dev/urandom.  Not all JavaScript engines have
the ability to selectively disable DOM APIs at runtime.

On Fri, Feb 11, 2011 at 10:00 AM, Cedric Vivier <cedricv at neonux.com> wrote:
> On Fri, Feb 11, 2011 at 19:38, Adam Barth <w3c at adambarth.com> wrote:
>> 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.
>
> Nice!
>
>> interface Crypto {
>>  void getRandomValues(in ArrayBufferView array) raises(DOMException);
>> };
>> If the ArrayBufferView isn't a Uint8Array , getRandomValues throws
>> an exception (VALIDATION_ERR
>
> Is there a specific reason for this limitation?
> Imho it should throw only for Float32Array and Float64Array since
> unbounded random floating numbers does not really make sense
> (including because of NaN and +inf -inf).
> However some use cases might prefer signed Int8Array or any other
> integer type and it doesn't change anything to the implementation :
> filling bytes to the ArrayBufferView's underlying ArrayBuffer).
>
> Like for instance you can do below in C to get random 32-bit numbers
> directly (though 'read' might very well get them one byte at a time
> from /dev/random) :
> int32_t random_32bit_integers[32];
> read(dev_random_fd, random_32bit_integers, sizeof(random_32bit_integers))

I went with a whitelist approach.  If there are other specific types
that you think we should whitelist, we can certainly do that.  Why
types, specifically, would you like to see supported?

Adam