[whatwg] Cryptographically strong random numbers

Erik Corry erik.corry at gmail.com
Tue Feb 22 05:31:54 PST 2011


Having got up to speed on this discussion after a holiday here are my
thoughts from a V8er:

* I would prefer to see this in the DOM rather than in the language.
Can't see why it needs to be in the language itself.  Other languages
generally don't have cryptographically secure random numbers in the
language itself, they put them in the libraries.  Other users of the
DOM http://www.w3.org/DOM/Bindings might want to use the feature too.
On the other hand this no big deal.   If  the committee feels that
putting it in the language makes it somehow more righteous then put it
there.

* But let's not invoke node.js as a reason to put it in the language.
Generally their policy is not to put things in the core that could be
libraries.  Seems to me that putting 'var crypto = require("crypto");'
works just fine for node and can give you a completely compatible
interface.

* Lets keep the interface simple.  All considerations of GC or
effciency look completely specious to me given the amount of data
involved (measured in bits).  Returning strings seems strange (crypto
data is numbers.  What about surrogate pairs - do we really want
something in the standard that returns incorrect UTF-16?).  I would be
in favour of any interface that returns regular arrays of numbers or
even simpler just a single number, either 0-1 like Math.random() or 8-
or 32-bit values.  But only one function please.

* I realize that Math.random() is not an ideal interface to emulate.
The reason I suggest it is that putting a new API into the core
language that is completely unlike Math.random() feels very PHP like:
http://www.tnx.nl/php.html  Even though Math.random() and the new
interface are not interchangeable it seems to me that there is value
in consistency in terms of mental effort needed to to memorize the
APIs.

2011/2/18 Oliver Hunt <oliver at apple.com>:
> 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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list