[whatwg] Cryptographically strong random numbers

[Oliver Hunt]

I don't think generating 16bit values is beneficial -- either 8bit values for byte at a time processing or full [u]int32 makes more sense.  I think the only reason for 16bit to come up is ecmascript's notionally 16bit characters.

I would prefer polymorphism of some form, for example

any gimmeRandom(numberOfRandomElements, constructor = [[]Builtin Array constructor], min = 0, max = 1<<32 - 1) {
    var result = new constructor(numberOfRandomElements);
    for (var i = 0; i < numberOfRandomElements; i++)
          result[i] = reallyRandomValue(min, max);
    return result;
}

This would solve all the use cases presented so far (except a string of cryptographically secure values, which can be handled trivially so i've left that as a task for the reader ;) ), and would avoid the shortcomings of the existing array methods (only a finite set of types can be produced as output).

--Oliver


On Feb 16, 2011, at 5:37 PM, Brendan Eich wrote:

> On Feb 16, 2011, at 5:33 PM, Allen Wirfs-Brock wrote:
> 
>> On Feb 16, 2011, at 4:54 PM, David Herman wrote:
>> 
>>> 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.
>> 
>> Dave, most browsers other than FF4 internally box all  integers with with 32-significant bits.
> 
> I'm not sure this is still true. Certainly on x64, but also on x86, NaN-boxing has taken over in many VMs.
> 
> 
>> Some may box with 31 or even 30 significant bits.  So if we spec. the value as a  uint32 and (they are truly random enough) then at least half and possible 75% or more of the values in the array will be boxed in many browsers.  Such boxing will have a much higher cost than immediate uint16 values.  That's why I propose 16-bit values.
> 
> Given the implementors on es-discuss, we should survey first. I'd hate to prematurely (de-)optimize.
> 
> I agree with David Wagner that the API has to be dead-simple, and it seems to me having only 16-bit values returned in a JS array may tend to result in more bit-mixing bugs than if we used 32-bit elements, if programmers are carelessly porting code that was written for uint32 arrays.
> 
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss