[whatwg] Cryptographically strong random numbers

[Adam Barth]

BTW, there seems to be significant interest around this subject here:

http://code.google.com/p/chromium/issues/detail?id=73226

w.r.t. the below, binary data types seem important for getting
randomness right.  In particular, using strings is bad news bears.  We
have binary data types available in browsers.  It would be a shame to
ignore them.

Adam


On Wed, Feb 16, 2011 at 4:29 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com> 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