[whatwg] Cryptographically strong random numbers

David Herman dherman at mozilla.com
Wed Feb 16 16:54:32 PST 2011

Too much and too complex, say I! ;)

I liked your previous thinking that we should just return a fresh array. And in the interest of keeping it dead simple, let's just fix it at 32 bits -- always.

Then the question is: string, array, typed array, or binary data?

I say: let's make it typed array in the short term, but TC39 will spec it as an array of uint32 according to the binary data spec. We will try to make the binary data spec as backwards compatible as possible with typed arrays anyway. So in the near term, implementors can use typed arrays, but when they have implementations of the full binary data spec, they can change to use those. It'll probably be a slightly backwards-incompatible change, but by keeping them relatively API-compatible, it shouldn't make too much difference in practice. Plus we can warn people that that change is coming.

So: Math.getRandomValues(length) or whatever you wanna call it, would just return a fresh array.

I might also be ok with extending it so that you can pass it an optional pre-existing array for it to mutate, for the sake of efficiency: Math.getRandomValues(length[, uint32array[, start]]).

(The window.crypto object could just be a reference to the same Math.getRandomValues function value.)


On Feb 16, 2011, at 4:29 PM, Allen Wirfs-Brock wrote:

> So, let's get back to the design of an actual ECMAScript API.
> I'll repeat a couple of initial points:
> We are now talking about a pure JavaScript API, not a DOM API so it should follow JavaScript conventions.
> If we want this to appear in browsers in the very near future we should minimize any dependencies upon other Harmony features  that are not both totally finalized and trivial to implement (the empty set??)
> The first point would seem to eliminate DOM-like conventions such as pseudo by-ref/in-our parameters, multiple numeric data types, or dependency upon any host object (DOM) array like objects.
> The second would seem to preclude the use of the proposed Harmony binary typed arrays.
> In general, I don't see any particular reason why an ECMAScript array would be unsuitable to collecting a sequence of random numeric values. It's what people do today when they need to manipulate sequences of numbers.
> If we are using array's, the simplest API is probably a new function on the array construct that is a factory for Arrays fill with random numeric values:
>  Array.randomFill= function (length){...};
> This would create a new array of the specified length where each element is a random value in some range.  I propose that this range be 0..65535 as these are easily manipulatable (and optimizable) values  that are likely to have some degree of optimization in all implementations.  I don't really see why other element ranges need to be supported as they are easily constructed these values.  However, if strong use cases (endianness??) can be made for the utility of natively supporting multiple element ranges then we could either add more functions:
>  Array.randomFill8(length)
>  Array.randomFill24(length)
>  Array.randomFill32(length)
> or accept an optimal second parameter that specifies the desired bit width:
>  Array.randomFill(length, bitWidth  /*1 .. (32?, 48?, 53?) */)
> I would recommend keeping it simple and avoiding such non-essential tweaks.
> There was some (it didn't seem very serious) concerns about the cost of array allocation for such calls.  I would point out  that creating a new array is already the technique used in ECMAScript for most somewhat comparable situations such as the results of RegExp matches, the set of items deleted by slice, etc. Others might invoke words about the desirability of a functional style...
> If the array allocation was really a concern, then the randomFill function should be a method on Array.prototyoe:
>  Array.prototype.randomFill= function () {...};   /* return the this value */
> it might be used like:
> 	var rand = new Array(8).randomFill();  //create an array of 8 random 16-bit numbers
> The length parameter is unnecessary because the length is implicit in the array (and if this is about perf. you probably don't want to be dynamically changing the length of already allocated arrays).
> The same discussion of element size alternatives also applies.
> Of course we could do both.  But really, if we want this to show up very soon in browsers keeping it to a single function or methods with minimal options is likely to yield the best results.
> Finally, as a dark horse we could consider using Strings rather than Arrays as JavaScript strings are sequences of 16-bit values and the individual element values are directly accessible.
> String.randomFill(length)  //returns a string value containing length random 16-bit character values.
> Individual values would be accessed as:
>   var rs=String.randomFill(2);
>   var random32=(rs.charCodeAt(0)<<16)|rs.charCodeAt(1);
> But really, Arrays seem like they should work just fine.
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

More information about the es-discuss mailing list