[whatwg] Cryptographically strong random numbers

Alex Russell alex at dojotoolkit.org
Tue Feb 22 06:10:05 PST 2011

On Feb 22, 2011, at 5:31 AM, Erik Corry wrote:

> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

Alex Russell
slightlyoff at google.com
slightlyoff at chromium.org
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

More information about the es-discuss mailing list