Re: [whatwg] Cryptographically strong random numbers

[Brendan Eich]

On Feb 22, 2011, at 3:45 PM, Erik Corry wrote:
> Thanks for the link. Having read the section in question I am satisfied that 
> the author has no problem with the API.
> 
In theory, sure. Bits are bits.

The practical issue is usability, where less usable interfaces tend to breed 
more bugs, as I argued was a hazard of the proposal to return a plain old Array 
containing uint16 values as elements. Glenn Maynard's point about more to go 
wrong with IEEE double seem to be validated by the IE9 preview release 
Math.random bugs that Amit Klein found. From the crypto-hacker point of view, 
anything that makes it harder to get random uint{8,16,32} values than necessary 
seems that much less good.

If we have only number type for the result, then Math.random is the API 
template to match. Given typed arrays / binary data, Adam's API looks more 
usable, even counting the cost of differing from Math.random in its API 
signature.

/be


> On Feb 23, 2011 12:34 AM, "Brendan Eich"  wrote:
> > On Feb 22, 2011, at 2:49 PM, Erik Corry wrote:
> >> I can find Klein's complaints that the implementation of Math.random is 
> >> insecure but not his complaints about the API. Do you have a link?
> > 
> > In the paper linked from http://seclists.org/bugtraq/2010/Dec/13 section 3 
> > ("3. The non-uniformity bug"), viz:
> > 
> > "Due to issues with rounding when converting the 54 bit quantity to a 
> > double precision number (as explained in 
> > http://www.trusteer.com/sites/default/files/Temporary_User_Tracking_in_Major_Browsers.pdf
> >  section 2.1, x2 may not accurately represent the state bits if the whole 
> > double precision number is ≥0.5."
> > 
> > but that link dangles, and I haven't had time to read more.
> > 
> > The general concern about the API arises because Adam's API returns a typed 
> > array result that could have lenght > 1, i.e., not a random result that 
> > fits in at most 32 (or even 53) bits.
> > 
> > /be
> ___
> es-discuss mailing list
> es-disc...@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

Re: [whatwg] Cryptographically strong random numbers

[Glenn Maynard]

On Tue, Feb 22, 2011 at 6:26 PM, Bill Frantz  wrote:

> On 2/22/11 at 1:36 PM, bren...@mozilla.com (Brendan Eich) wrote:
>
>  However, Math.random is a source of bugs as Amit Klein has shown, and
>> these can't all be fixed by using a better non-CS PRNG underneath
>> Math.random and still decimating to an IEEE double in [0, 1]. The use-cases
>> Klein explored need both a CS-PRNG and more bits, IIRC. Security experts
>> should correct amateur-me if I'm mistaken.
>>
>
> I'll see if the security expert hat fits. :-)
>
> The random() function in many languages has a useful property which is
> incompatible with security. By setting its seed, you can get deterministic
> execution of a Monte Carlo algorithm.


I don't agree that being able to query and set the state of a PRNG is
incompatible with security.  Most comprehensive, secure PRNG APIs support
doing that, eg. LTC's "XXX_import" and "XXX_export" functions.  In fact, you
can even do that with /dev/urandom in Linux (only as root, since it's shared
across users).  Neither Math.random nor any of the APIs discussed so far are
attempt to be comprehensive APIs, of course.

Using Math.random's API for secure random numbers wouldn't make sense,
though.  Secure random number sources from OS's give bytes, and most (all?)
real-world crypto algorithms want bytes (or groups of bytes), so this would
just be converting from bytes to floating-point and back to bytes anyway.
That's just introducing a lot of new ways to get things wrong.

-- 
Glenn Maynard

Re: [whatwg] Cryptographically strong random numbers

[Erik Corry]

Thanks for the link. Having read the section in question I am satisfied that
the author has no problem with the API.
On Feb 23, 2011 12:34 AM, "Brendan Eich"  wrote:
> On Feb 22, 2011, at 2:49 PM, Erik Corry wrote:
>> I can find Klein's complaints that the implementation of Math.random is
insecure but not his complaints about the API. Do you have a link?
>
> In the paper linked from http://seclists.org/bugtraq/2010/Dec/13 section 3
("3. The non-uniformity bug"), viz:
>
> "Due to issues with rounding when converting the 54 bit quantity to a
double precision number (as explained in
http://www.trusteer.com/sites/default/files/Temporary_User_Tracking_in_Major_Browsers.pdfsection
2.1, x2 may not accurately represent the state bits if the whole
double precision number is ≥0.5."
>
> but that link dangles, and I haven't had time to read more.
>
> The general concern about the API arises because Adam's API returns a
typed array result that could have lenght > 1, i.e., not a random result
that fits in at most 32 (or even 53) bits.
>
> /be

Re: [whatwg] Cryptographically strong random numbers

[Brendan Eich]

On Feb 22, 2011, at 2:49 PM, Erik Corry wrote:
> I can find Klein's complaints that the implementation of Math.random is 
> insecure but not his complaints about the API.  Do you have a link?

In the paper linked from http://seclists.org/bugtraq/2010/Dec/13 section 3 ("3. 
The non-uniformity bug"), viz:

"Due to issues with rounding when converting the 54 bit quantity to a double 
precision number (as explained in 
http://www.trusteer.com/sites/default/files/Temporary_User_Tracking_in_Major_Browsers.pdf
 section 2.1, x2 may not accurately represent the state bits if the whole 
double precision number is ≥0.5."

but that link dangles, and I haven't had time to read more.

The general concern about the API arises because Adam's API returns a typed 
array result that could have lenght > 1, i.e., not a random result that fits in 
at most 32 (or even 53) bits.

/be

Re: [whatwg] Cryptographically strong random numbers

[Erik Corry]

I can find Klein's complaints that the implementation of Math.random is
insecure but not his complaints about the API.  Do you have a link?

It seems pretty simple to generate a random number from 1 to 2 by fixing the
exponent and mixing in 52 bits of random mantissa. Subtract 1 to get an
evenly distributed value from 0-1. Multiply and Math.floor or >>> to get
your 8, 16, or 32 bits of randomness.
On Feb 22, 2011 11:04 PM, "Brendan Eich"  wrote:
> On Feb 22, 2011, at 2:00 PM, Jorge wrote:
>
>> On 22/02/2011, at 22:36, Brendan Eich wrote:
>>> (...)
>>>
>>> However, Math.random is a source of bugs as Amit Klein has shown, and
these can't all be fixed by using a better non-CS PRNG underneath
Math.random and still decimating to an IEEE double in [0, 1]. The use-cases
Klein explored need both a CS-PRNG and more bits, IIRC. Security experts
should correct amateur-me if I'm mistaken.
>>
>> .replace( /1]/gm, '1)' ) ?
>
> Right.
>
> Reading more of Amit Klein's papers, the rounding to IEEE double also
seems problematic. Again, I'm not the crypto-droid you are looking for.
>
> /be
>

Re: [whatwg] Cryptographically strong random numbers

[Brendan Eich]

On Feb 22, 2011, at 2:00 PM, Jorge wrote:

> On 22/02/2011, at 22:36, Brendan Eich wrote:
>> (...)
>> 
>> However, Math.random is a source of bugs as Amit Klein has shown, and these 
>> can't all be fixed by using a better non-CS PRNG underneath Math.random and 
>> still decimating to an IEEE double in [0, 1]. The use-cases Klein explored 
>> need both a CS-PRNG and more bits, IIRC. Security experts should correct 
>> amateur-me if I'm mistaken.
> 
> .replace( /1]/gm, '1)' ) ?

Right.

Reading more of Amit Klein's papers, the rounding to IEEE double also seems 
problematic. Again, I'm not the crypto-droid you are looking for.

/be

Re: [whatwg] Cryptographically strong random numbers

[Jorge]

On 22/02/2011, at 22:36, Brendan Eich wrote:
> (...)
> 
> However, Math.random is a source of bugs as Amit Klein has shown, and these 
> can't all be fixed by using a better non-CS PRNG underneath Math.random and 
> still decimating to an IEEE double in [0, 1]. The use-cases Klein explored 
> need both a CS-PRNG and more bits, IIRC. Security experts should correct 
> amateur-me if I'm mistaken.

.replace( /1]/gm, '1)' ) ?
-- 
Jorge.

Re: [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-disc...@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

Re: [whatwg] Cryptographically strong random numbers

[Cedric Vivier]

On Thu, Feb 17, 2011 at 08:29, Allen Wirfs-Brock  wrote:
>  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...


As Glenn pointed out, efficiency is just one part of the concern.
Flexibility is the main one. The fact you struggle to propose an API
that can satisfy everyone with 4 different randomFill functions rings
'code smell' to me.

You are making policy decisions on what kind of values (eg "only
0..65535") you can get from it and might severely hamper use cases
where efficiency is important (eg. just on top of my head, _stream_
random data to WebGL or WebGL) while it is always possible to create
an array before the call if you want to (or write a 3 line wrapper to
do that).

In fact most other languages/frameworks work this way, and I'm not
sure it makes sense in the first place to have this kind of specific
'seldom used' function in the language and/or such a basic and
commonly used type as Array, compared to have it in a type providing
crypto features (eg. .crypto).


Regards,

Re: [whatwg] Cryptographically strong random numbers

[Allen Wirfs-Brock]

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.  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.

Allen

Re: [whatwg] Cryptographically strong random numbers

[Tom Mitchell]

On Wed, 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,


Good stuff.

Recall that part of what started this is that folks
asked for improvements to math.random but math.random had
become a key function in many benchmarks.
Improving math.random would have the side effect of
slowing down benchmark results so some felt touching
is was problematic.

Then there were some discussions regarding security hacks
where guessing or inserting well guessed or spoofed results
could compromise business or privacy.  One post had a good
yet short list of links that made it clear that Math.random as it is, is
fragile.

Rather than define a full and new API, an alternate tactic might be  to code up
some "quality" benchmarks metrics where Math.random would be improved
because the benchmarks that identified the quality of the random numbers and
gave better random tools more  weighted value than just wall clock speed.

The other issue that surfaced was a lack of rand-seed management
policy.  If corrected that would effectively make it nearly impossible for
one script to guess anything that might go on in another connection.

It is important for the old Math.random and any new API  that
rand-seed management
policy be well addressed.

I only intend to make the point that a new API will not repair Math.random
as used now by numerous sites.   Adding a new API will give sites new
ways to get it wrong.



-- 

                      T o m   M i t c h e l l
                    mitch-at-niftyegg-dot-com
"My lifetime goal is to be the kind of person my dogs think I am."

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

Also note that that bug is accumulating use cases that might be worth
considering in this effort.  As an example, many banks in various
parts of Asia require the use of ActiveX controls in IE.  One could
hope that the web platform could provide those sorts of facilities
natively.

Adam


On Wed, Feb 16, 2011 at 5:00 PM, Adam Barth  wrote:
> 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
>  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
>

Re: [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
 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

Re: [whatwg] Cryptographically strong random numbers

[Allen Wirfs-Brock]

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

Re: [whatwg] Cryptographically strong random numbers

[Glenn Maynard]

On Mon, Feb 14, 2011 at 8:03 PM, Allen Wirfs-Brock wrote:

> but we're now talking about a pure ECMAScript function so DOM conventions
> shouldn't be applicable.  But consistency with common JavaScript practices
> should be.
>
> If you want to apply it to an already allocated array then making it method
> on Array.prototype would be a more internally consistent way to do it.
>
> Although, I also a bit partial to the string based formulation and I assume
> that relatively small string values should be fairly efficient to allocated.
>
> In either case, it does sound like premature optimization relative to
> everything else that is likely to beging on the the JS code that actually
> uses these random values.
>

This isn't an optimization; it's simply a different design.  Optimization is
one underlying rationale, but not the only one.

I don't think optimization is an important consideration here for crypto,
since you usually don't need a lot of random data to generate a key--often
on the order of a few dozen or hundred bytes.  You're not reading a megabyte
of data to generate a key.  There can be uses for generating large blocks of
randomness for non-crypto, though, of course.

However, it also allows specifying the type of the data to return: whether
the random data should be interpreted as 8-bit arrays, 16-bit arrays, and so
on.  I don't know if that's actually important (havn't seen specific use
cases), but that was another rationale.  I think it was also intended to
avoid encoding 8-bit data in a UTF-16 string.

-- 
Glenn Maynard

Re: [whatwg] Cryptographically strong random numbers

[Mark S. Miller]

On Wed, Feb 16, 2011 at 11:36 AM, Oliver Hunt  wrote:

> I agree with this sentiment, the specification should simply state "the
> returned values are guaranteed to be cryptographically secure", that's all
> that needs to be said.  There is no need to describe how this is
> implemented, if an implementation provides predictable values then that
> implementation is broken.  If your prng has low entropy it is not
> cryptographically secure, and therefore broken.  How you get to
> cryptographically secure isn't really relevant as long as you can get
> there*.
>
> This is of course entirely ignoring timing attacks, and other such side
> channels.
>
> --Oliver
>
> * If a platform can't provide cryptographically secure random i'd be
> concerned about that implementation being web facing as i would be dubious
> of the theoretical security of its SSL implementation, etc.
>

Hi Oliver, not disagreeing with anything you said. But in light of this
footnote, I want to remind everyone that JS is not necessarily web facing.
Normative EcmaScript standards impose an obligation on any implementation
wishing to claim standards conformance. That said, I support adding this
normative obligation on all conformant EcmaScript implementations.




>
>
> On Feb 16, 2011, at 10:40 AM, David Wagner wrote:
>
> > [re-sending to es-discuss]
> >
> > Shabsi Walfish wrote:
> >> This depends on what you consider to be the basic use case. Generating
> >> long-lived cryptographic keys absolutely requires high quality
> entropy... if
> >> you are only generating short-lived authenticators (that are not used
> for
> >> encryption) then you could get away with weaker entropy. You will get
> the
> >> most mileage out of this feature if it can be used to generate
> encryption
> >> keys, or long-lived signing keys.
> >
> > Personally, I think discussion about the "quality" of the PRNG is a
> > distraction.  The PRNG should produce crypto-quality random numbers.
> > Period.  That's all that need be said.  That's good enough.  It's good
> > enough for short-lived authenticators, good enough for encryption keys,
> > good enough for any signing key that's going to be used in Javascript.
> > It's just plain good enough.
> >
> > There's no need for an interface to request or query or specify the
> > quality or entropy of the random numbers.  Callers should be able to
> > rely upon it to be crypto-quality.  Browsers can deliver on that.
> >
> > My advice is: Keep the API as simple as it possibly can be.  Don't get
> > distracted with twirly knobs and added complications.  A simple API will
> > be plenty to get the job done.  Stay on target.
> > ___
> > es-discuss mailing list
> > es-disc...@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Cheers,
--MarkM

Re: [whatwg] Cryptographically strong random numbers

[Oliver Hunt]

I agree with this sentiment, the specification should simply state "the 
returned values are guaranteed to be cryptographically secure", that's all that 
needs to be said.  There is no need to describe how this is implemented, if an 
implementation provides predictable values then that implementation is broken.  
If your prng has low entropy it is not cryptographically secure, and therefore 
broken.  How you get to cryptographically secure isn't really relevant as long 
as you can get there*.

This is of course entirely ignoring timing attacks, and other such side 
channels.

--Oliver

* If a platform can't provide cryptographically secure random i'd be concerned 
about that implementation being web facing as i would be dubious of the 
theoretical security of its SSL implementation, etc.


On Feb 16, 2011, at 10:40 AM, David Wagner wrote:

> [re-sending to es-discuss]
> 
> Shabsi Walfish wrote:
>> This depends on what you consider to be the basic use case. Generating
>> long-lived cryptographic keys absolutely requires high quality entropy... if
>> you are only generating short-lived authenticators (that are not used for
>> encryption) then you could get away with weaker entropy. You will get the
>> most mileage out of this feature if it can be used to generate encryption
>> keys, or long-lived signing keys.
> 
> Personally, I think discussion about the "quality" of the PRNG is a
> distraction.  The PRNG should produce crypto-quality random numbers.
> Period.  That's all that need be said.  That's good enough.  It's good
> enough for short-lived authenticators, good enough for encryption keys,
> good enough for any signing key that's going to be used in Javascript.
> It's just plain good enough.
> 
> There's no need for an interface to request or query or specify the
> quality or entropy of the random numbers.  Callers should be able to
> rely upon it to be crypto-quality.  Browsers can deliver on that.
> 
> My advice is: Keep the API as simple as it possibly can be.  Don't get
> distracted with twirly knobs and added complications.  A simple API will
> be plenty to get the job done.  Stay on target.
> ___
> es-discuss mailing list
> es-disc...@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

Re: [whatwg] Cryptographically strong random numbers

[Glenn Maynard]

On Mon, Feb 14, 2011 at 7:20 PM, Shabsi Walfish  wrote:

> Hmm... if there is a guarantee that /dev/urandom was successfully seeded at
> some point in the past, then I'm happy with it. Is there such a guarantee? I
> don't see that documented anywhere, and I'm not sure how it would be
> provided. Since /dev/urandom never blocks, I'm assuming it will return
> something based mostly on weak entropy sources (like system time and/or or a
> very small number of real bits of entropy) in the event that the system
> hasn't really had a chance to seed the pool yet. I can live with not
> reliably refreshing the pool, but its pretty scary if you think about what
> happens when a user boots their phone up for the first time, etc. and there
> is just no entropy there yet.
>

There's no strict guarantee, since there's no API for /dev/urandom to refuse
to generate data if there's no entropy whatsoever.  I suppose software can
read entropy_avail to make sure that there's at least something in there,
though I don't know if anything actually does that, and if that's something
entropy_avail is actually meant to be used for.

I don't think trying to expand this API for this--for example, a parameter
saying "throw an exception if the entropy buffer is empty"--would be
helpful.  The cases that this happens are extremely narrow, and essentially
nonexistant on a running system; it would either never be used or result in
extremely poorly-tested code paths (both in UAs and in user code), and would
complicate things quite a lot (how long do you wait before trying again?).

(As an aside, I also don't know the state of hardware entropy generation on
modern hardware, which can likely generate entropy much more robustly than
the old hacks of mixing in interrupt timing and mouse movement, eliminating
the old problem of filling the entropy buffer from a first-time cold boot.)

-- 
Glenn Maynard

Re: [whatwg] Cryptographically strong random numbers

[Brendan Eich]

On Feb 14, 2011, at 3:03 PM, Allen Wirfs-Brock wrote:

> And why overwrite the elements of an existing array?  Why not just creating a 
> new Array and use the argument to specify the desired length?

Just to respond to this, I believe the reusable buffer is an optimization 
(premature? perhaps not for those JS VMs that lack super-fast generational GC) 
to allow the API user to amortize allocation overhead across many calls to 
getRandomValues. Of course, with a fast enough GC or few enough calls, this 
optimization doesn't matter.

The IDL's use of an array inout parameter also supports efficient bindings for 
languages with stack allocation, which is a non-trivial win in C and C++ not 
only compared to malloc performance-wise, but also for automated cleanup (vs. 
intrinsic cost of free, plus on some OSes, "which free do I call"?).

/be

Re: [whatwg] Cryptographically strong random numbers

[Glenn Maynard]

On Mon, Feb 14, 2011 at 6:43 PM, Shabsi Walfish  wrote:

> OpenSSL is not exactly a reliable source of cryptographic best practices.
> :) In any case, see here http://linux.die.net/man/4/urandom :


No single implementation is; neither are Linux manpages.  The question is
whether there are security issues when generating long-term keys from a
secure PRNG (RC4, Yarrow, Fortuna) from an entropy pool that's been seeded
but exhausted.  I suspect that question has been examined at great length by
others in the past, so I doubt there's new ground for us to cover on this.
It would be interesting if anyone knows of any competent analysis of this
question (preferably in a form written for non-cryptographers).

In any case, an API which returns random data with a guarantee of entropy
inherently must block, like /dev/random does.  That implies an asynchronous
API, taking a callback which is called when the requested data is
available.  Even if that's ultimately wanted, it would be a separate API.

(Of course, if that API is created later, then it should be similar to this
one--an asynchronous version of this synchronous API.  I can think of some
minor speed bumps to making an async version of this API--you don't want to
write to the array asynchronously, while other code is running--but nothing
unreasonable.)

-- 
Glenn Maynard

Re: [whatwg] Cryptographically strong random numbers

[Brendan Eich]

On Feb 14, 2011, at 1:29 PM, Adam Barth wrote:

> On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich  wrote:
> On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:
>> On Mon, Feb 14, 2011 at 11:56 AM, Brendan Eich  wrote:
>> On Feb 14, 2011, at 11:31 AM, Adam Barth wrote:
>>> What's non-interoperable about filling an ArrayBuffer with random bytes?  
>>> I'm not sure I understand your question.
>> The question is what OSes fail to provide enough random bits these days.
>> 
>> This may just be a sanity-checking step (my sanity, at least; I lived 
>> through the great entropy hunt of 1995; 
>> http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html [link courtesy 
>> dwagner]).
>> 
>> Somehow OpenSSL and NSS seem to solve that problem given that cryptographic 
>> entropy is required to make HTTPS secure.  I'm certainly willing to believe 
>> I've goofed it up, but I suspect it's not that much of a limitation these 
>> days.
> 
> I'm happy if the answer is "all OSes, mobile and desktop, provide enough high 
> quality randomness". Looking for data if anyone has it.
> 
> As far as I can tell, /dev/urandom works great on all modern Unix-derived 
> operating systems (e.g., Mac, Linux, BSD, iOS, Android).  Windows since 
> Windows 2000 has CryptGenRandom:
> 
> http://msdn.microsoft.com/en-us/library/aa379942(v=vs.85).aspx
> 
> Are there other operating systems you're worried about?

Not for Mozilla (see below about BeOS). So as not to put up "stop energy", let 
me say this is great news, and I hope we're done.

In parallel, hearing "all clear" from Ecma and W3C members who care about 
Symbian, Nokia's Linux-based stuff, anything not modern Windows (older mobile 
stuff), or the various proprietary real-time/embedded OSes would be helpful.


> Ok.  We can change the API to be like that, if you like.  In WebKit, 
> USE(OS_RANDOMNESS) is defined on virtually every port.  There might be some 
> ports that aren't covered (e.g., BeOS) though.

Heh, Mozilla has a BeOS 'port, along with other OS/CPU targets that are not 
"tier 1" (where tier 1 has /dev/urandom or CryptGenRandom). I think the Amiga 
port died years ago ;-). But these can do without. The question is what the 
mechanics of "doing without" should be (runtime exception or no method 
detected).


> There seems to be some spin here. What does "today" mean, and why the loaded 
> "multi-month (year?) process" and "all-sing[ing]" etc. imputations to Ecma? I 
> hope you are not describing how quickly you can hack on WebKit code, because 
> while I can hack quickly on Mozilla code, that does not set the pace of a 
> standard, never mind make a new feature available cross-browser to web 
> developers.
> 
> Maybe I misunderstood TC39's intentions.  My understanding is that your 
> aspirations include a full-featured crypto library, e.g., at the level of 
> complexity of OpenSSL rather than at the complexity of arc4random.  Certainly 
> designing and implementing such a feature is a longer-term prospect.

Mark suggested such a program, and I like the idea (as you clearly do, cited 
below), but TC39 as a committee has not bought into it yet.

Putting aside the idea of a larger crypto library TC39 task group, Mark did 
make a special case for the RBG in the core language, since Math.random is in 
the core language, cannot be removed, yet is also a footgun.

This has been TC39's position: whatever we do with a separate task group for a 
crypto library, we have a Harmony agenda item, represented by that

http://wiki.ecmascript.org/doku.php?id=strawman:random-er

place-holder proposal.


> While it indeed takes years to produce new Ecma (ISO) specs, we on TC39 
> support early prototyping of harmonious proposals, so web developers can 
> start using such candidate features. But for this to work we need a 
> hand-shake on what is harmonious.
> 
> If the idea is to promulgate a de-facto standard via Chrome and let other 
> browsers reverse-engineer it, that can work, but it could backfire.
> 
> If that were my intention, we wouldn't be having this discussion.

I think you're probably right that whatwg could get some crypto.getRandomValues 
spec together faster. For one, you've already done a bunch of work in that 
context!

But I see the situation as fluid, no matter what standards body claims 
jurisdiction. If we prototype and test something successfully, then (with name 
changes if necessary) it could be put into either standard process. Neither 
process is "fast", since for IPR release the whatwg one still must flow into 
w3c.

So my point is that nothing in the current standards bodies necessitates that 
an RBG proto-spec appears "today" in the whatwg context, vs. years from now in 
Ecma. Maybe we should have two APIs, but as David Bruant just argued, wouldn't 
it be better to have only one?

The Chrome idea is not only a matter of your intentions. It could happen no 
matter what you intend, and that could be a good thing, too -- in the best 
case. I've promulgated de-facto standard

Re: [whatwg] Cryptographically strong random numbers

[Glenn Maynard]

On Mon, Feb 14, 2011 at 5:46 PM, Shabsi Walfish  wrote:

> This depends on what you consider to be the basic use case. Generating
> long-lived cryptographic keys absolutely requires high quality entropy... if
> you are only generating short-lived authenticators (that are not used for
> encryption) then you could get away with weaker entropy. You will get the
> most mileage out of this feature if it can be used to generate encryption
> keys, or long-lived signing keys.


OpenSSL gets randomness for generating keys by reading /dev/urandom.  It
doesn't seem to do any other tricks, like reading
/proc/sys/kernel/random/entropy_avail.  That at least suggests it's
sufficient for securely generating keys, without more complex APIs like
exposing the amount of entropy that was available.

-- 
Glenn Maynard

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

[Hopefully my subscription change to es-discuss has gone through by now.]

On Mon, Feb 14, 2011 at 2:25 PM, Mark S. Miller  wrote:
> While we're waiting for Adam to subscribe to es-discuss and repost his
> messages on this thread, this one seems worth pre-posting.
>
> Changes needed for this to become an EcmaScript strawman:
> Replace references to ArrayBufferView with appropriate abstractions from
> .
> Replace WebIDL as a specification language with a JavaScript based API spec.
>
> Get rid of the dependence on "window". Probably avoid introducing a new
> global "crypto" as well, though we can argue about that.

For what it's worth, the "crypto" global already exists and my
understanding is that it's actually required for web compatibility
(although I think supplying the empty object is sufficient to feed the
compat demon).

You'll also want to change the exceptions because those are DOM exceptions.

Adam


> Are there any other lurking browser dependencies in Adam's spec that we need
> to scrub away?
>
> On Mon, Feb 14, 2011 at 2:08 PM, Adam Barth  wrote:
>>
>> On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich 
>> wrote:
>> > On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:
>> > > Ok.  I'll write up a spec later today.
>> >
>> > Thanks.
>>
>> Done: http://wiki.whatwg.org/wiki/Crypto
>>
>> Feedback appreciated.
>>
>> Adam
>
>
>
> --
>     Cheers,
>     --MarkM
>

Re: [whatwg] Cryptographically strong random numbers

[Glenn Maynard]

On Mon, Feb 14, 2011 at 5:08 PM, Adam Barth  wrote:

> On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich 
> wrote:
> > On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:
> > > Ok.  I'll write up a spec later today.
> >
> > Thanks.
>
> Done: http://wiki.whatwg.org/wiki/Crypto
>
> Feedback appreciated.
>

> If insufficient cryptographically random values are available,
getRandomValues does not alter array and throws a NOT_SUPPORTED_ERR

I'm not sure if this means "if you're using /dev/random and it would block,
throw", or "if the amount of entropy in the PRNG's entropy pool is low,
throw", but they both seem hard to deal with from scripts.  There's no way
to know when to try again, and most applications wanting secure PRNGs don't
need this.  Even ssh-keygen seems to simply use /dev/urandom without
worrying about it returning low-entropy randomness.

I think it makes more sense to imply /dev/urandom's behavior: always return
data, even if the entropy pool is low.  If there's a need for randomness
with that stronger guarantee of entropy, that seems like it would want an
asynchronous API in order to wait for entropy (akin to /dev/random).

-- 
Glenn Maynard

Re: [whatwg] Cryptographically strong random numbers

[Mark S. Miller]

While we're waiting for Adam to subscribe to es-discuss and repost his
messages on this thread, this one seems worth pre-posting.

Changes needed for this to become an EcmaScript strawman:

Replace references to ArrayBufferView with appropriate abstractions from <
http://wiki.ecmascript.org/doku.php?id=strawman:binary_data>.
Replace WebIDL as a specification language with a JavaScript based API spec.
Get rid of the dependence on "window". Probably avoid introducing a new
global "crypto" as well, though we can argue about that.

Are there any other lurking browser dependencies in Adam's spec that we need
to scrub away?


On Mon, Feb 14, 2011 at 2:08 PM, Adam Barth  wrote:

> On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich 
> wrote:
> > On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:
> > > Ok.  I'll write up a spec later today.
> >
> > Thanks.
>
> Done: http://wiki.whatwg.org/wiki/Crypto
>
> Feedback appreciated.
>
> Adam
>



-- 
Cheers,
--MarkM

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich  wrote:
> On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:
> > Ok.  I'll write up a spec later today.
>
> Thanks.

Done: http://wiki.whatwg.org/wiki/Crypto

Feedback appreciated.

Adam

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich  wrote:

> On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:
>
> On Mon, Feb 14, 2011 at 11:56 AM, Brendan Eich wrote:
>
>> On Feb 14, 2011, at 11:31 AM, Adam Barth wrote:
>>
>> What's non-interoperable about filling an ArrayBuffer with random bytes?
>>  I'm not sure I understand your question.
>>
>> The question is what OSes fail to provide enough random bits these days.
>>
>> This may just be a sanity-checking step (my sanity, at least; I lived
>> through the great entropy hunt of 1995;
>> http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html [link courtesy
>> dwagner]).
>>
>
> Somehow OpenSSL and NSS seem to solve that problem given that cryptographic
> entropy is required to make HTTPS secure.  I'm certainly willing to believe
> I've goofed it up, but I suspect it's not that much of a limitation these
> days.
>
>
> I'm happy if the answer is "all OSes, mobile and desktop, provide enough
> high quality randomness". Looking for data if anyone has it.
>

As far as I can tell, /dev/urandom works great on all modern Unix-derived
operating systems (e.g., Mac, Linux, BSD, iOS, Android).  Windows since
Windows 2000 has CryptGenRandom:

http://msdn.microsoft.com/en-us/library/aa379942(v=vs.85).aspx

Are there other operating systems you're worried about?


> However, I'm disinclined to wait on the basic best-effort PRNG for that to
>> happen.
>>
>>
>> What would you be waiting for? Ignoring Ecma, just adding code to WebKit
>> doesn't make a cross-browser standard. Never mind Firefox (we'll do
>> something soon enough to match). What about IE?
>>
>
> Given that we've missed IE9, we're talking about IE10 at the earliest.  If
> history is a guide (which it might not be), that means we're talking about
> something 2 years in the future.
>
>
> Oh, who knows what any vendor will do under modern competitive pressure.
> Let's not assume :-/. My point is: to engage all the major browser vendors,
> we need a spec, not four-line (net of #ifdefs) patches.
>
> Here is another spec-worthy issue that IDL can't capture (and if we choose
> one way, can't even express): the #ifdefs raise the question (which David
> Wagner and I discussed briefly in private correspondence, and which I see
> came up on the whatwg list already) of whether it is better to provide a
> throwing stub when the OS randomness configury is not enabled, or better not
> to provide an object-detectible method at all?
>
> I'm inclined toward not providing a method that always throws. I've seen
> too much fool's gold mislead developers. Bugs and throwing stubs underlying
> detectible methods have led web developers to not just object-detect, but
> unit-test online! (See
> http://www.slideshare.net/jeresig/the-dom-is-a-mess-yahoo .) But testing
> detectible methods for correctness further bloats downloaded JS and slows
> first-run execution.
>

Ok.  We can change the API to be like that, if you like.  In WebKit,
USE(OS_RANDOMNESS) is defined on virtually every port.  There might be some
ports that aren't covered (e.g., BeOS) though.


> Ok.  I'll write up a spec later today.
>
>
> Thanks.
>
> On Mon, Feb 14, 2011 at 12:15 PM, Mark S. Miller 
>  wrote:
>
>  As has already been discussed, since these issues are general EcmaScript
>> issues, applying not just in the browser but in many places JavaScript is
>> run (e.g., nodejs), I suggest that this be the last message on this thread
>> cross-posted to whatwg. Unless someone has a reason for retaining whatwg in
>> the addressee list, I will drop it from all my further postings on this
>> thread.
>>
>
> Actually, that is precisely what we're discussing.  My suggestion is that
> we do both: browsers implement a simple DOM-based API today that handles the
> basic arc4random-like use case and TC39 go through whatever multi-month
> (year?) process it likes and spec out whatever all-sing, all-dance crypto
> library it likes.
>
>
> There seems to be some spin here. What does "today" mean, and why the
> loaded "multi-month (year?) process" and "all-sing[ing]" etc. imputations to
> Ecma? I hope you are not describing how quickly you can hack on WebKit code,
> because while I can hack quickly on Mozilla code, that does not set the pace
> of a standard, never mind make a new feature available cross-browser to web
> developers.
>

Maybe I misunderstood TC39's intentions.  My understanding is that your
aspirations include a full-featured crypto library, e.g., at the level of
complexity of OpenSSL rather than at the complexity of arc4random.
 Certainly designing and implementing such a feature is a longer-term
prospect.


> While it indeed takes years to produce new Ecma (ISO) specs, we on TC39
> support early prototyping of harmonious proposals, so web developers can
> start using such candidate features. But for this to work we need a
> hand-shake on what is harmonious.
>
> If the idea is to promulgate a de-facto standard via Chrome and let other
> browsers reverse-engineer it, th

Re: [whatwg] Cryptographically strong random numbers

[Mike Shaver]

On Fri, Feb 11, 2011 at 1:36 PM, Adam Barth  wrote:
> Regardless, the ability does not exist in JavaScriptCore.  If you'd
> like to contribute a patch that makes it possible, I'm sure it would
> be warmly received.

That is surprising to me. Isn't it necessary in order to implement
window.forms. and other dynamically-reflected properties?

Mike

Re: [whatwg] Cryptographically strong random numbers

[Brendan Eich]

On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:

> On Mon, Feb 14, 2011 at 11:56 AM, Brendan Eich  wrote:
> On Feb 14, 2011, at 11:31 AM, Adam Barth wrote:
>> What's non-interoperable about filling an ArrayBuffer with random bytes?  
>> I'm not sure I understand your question.
> The question is what OSes fail to provide enough random bits these days.
> 
> This may just be a sanity-checking step (my sanity, at least; I lived through 
> the great entropy hunt of 1995; 
> http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html [link courtesy 
> dwagner]).
> 
> Somehow OpenSSL and NSS seem to solve that problem given that cryptographic 
> entropy is required to make HTTPS secure.  I'm certainly willing to believe 
> I've goofed it up, but I suspect it's not that much of a limitation these 
> days.

I'm happy if the answer is "all OSes, mobile and desktop, provide enough high 
quality randomness". Looking for data if anyone has it.


>> However, I'm disinclined to wait on the basic best-effort PRNG for that to 
>> happen.
> 
> What would you be waiting for? Ignoring Ecma, just adding code to WebKit 
> doesn't make a cross-browser standard. Never mind Firefox (we'll do something 
> soon enough to match). What about IE?
> 
> Given that we've missed IE9, we're talking about IE10 at the earliest.  If 
> history is a guide (which it might not be), that means we're talking about 
> something 2 years in the future.

Oh, who knows what any vendor will do under modern competitive pressure. Let's 
not assume :-/. My point is: to engage all the major browser vendors, we need a 
spec, not four-line (net of #ifdefs) patches.

Here is another spec-worthy issue that IDL can't capture (and if we choose one 
way, can't even express): the #ifdefs raise the question (which David Wagner 
and I discussed briefly in private correspondence, and which I see came up on 
the whatwg list already) of whether it is better to provide a throwing stub 
when the OS randomness configury is not enabled, or better not to provide an 
object-detectible method at all?

I'm inclined toward not providing a method that always throws. I've seen too 
much fool's gold mislead developers. Bugs and throwing stubs underlying 
detectible methods have led web developers to not just object-detect, but 
unit-test online! (See 
http://www.slideshare.net/jeresig/the-dom-is-a-mess-yahoo .) But testing 
detectible methods for correctness further bloats downloaded JS and slows 
first-run execution.


> Ok.  I'll write up a spec later today.

Thanks.


> On Mon, Feb 14, 2011 at 12:15 PM, Mark S. Miller  wrote:
> As has already been discussed, since these issues are general EcmaScript 
> issues, applying not just in the browser but in many places JavaScript is run 
> (e.g., nodejs), I suggest that this be the last message on this thread 
> cross-posted to whatwg. Unless someone has a reason for retaining whatwg in 
> the addressee list, I will drop it from all my further postings on this 
> thread.
> 
> Actually, that is precisely what we're discussing.  My suggestion is that we 
> do both: browsers implement a simple DOM-based API today that handles the 
> basic arc4random-like use case and TC39 go through whatever multi-month 
> (year?) process it likes and spec out whatever all-sing, all-dance crypto 
> library it likes.

There seems to be some spin here. What does "today" mean, and why the loaded 
"multi-month (year?) process" and "all-sing[ing]" etc. imputations to Ecma? I 
hope you are not describing how quickly you can hack on WebKit code, because 
while I can hack quickly on Mozilla code, that does not set the pace of a 
standard, never mind make a new feature available cross-browser to web 
developers.

While it indeed takes years to produce new Ecma (ISO) specs, we on TC39 support 
early prototyping of harmonious proposals, so web developers can start using 
such candidate features. But for this to work we need a hand-shake on what is 
harmonious.

If the idea is to promulgate a de-facto standard via Chrome and let other 
browsers reverse-engineer it, that can work, but it could backfire.

Extending the old window.crypto object we added ages ago at Netscape may be a 
good idea and a faster route to a high-quality cross-browser RBG. I won't argue 
about that. My objection here is to your choice of words and the way they might 
foreclose better cooperation among vendors: such an RBG API is not done 
"today", and it needs more than just one implementation to be a standard other 
browsers will implement.

/be

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

On Mon, Feb 14, 2011 at 11:56 AM, Brendan Eich  wrote:

> On Feb 14, 2011, at 11:31 AM, Adam Barth wrote:
>
> What's non-interoperable about filling an ArrayBuffer with random bytes?
>  I'm not sure I understand your question.
>
> The question is what OSes fail to provide enough random bits these days.
>
> This may just be a sanity-checking step (my sanity, at least; I lived
> through the great entropy hunt of 1995;
> http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html [link courtesy
> dwagner]).
>

Somehow OpenSSL and NSS seem to solve that problem given that cryptographic
entropy is required to make HTTPS secure.  I'm certainly willing to believe
I've goofed it up, but I suspect it's not that much of a limitation these
days.

 However, I'm disinclined to wait on the basic best-effort PRNG for that to
> happen.
>
>
> What would you be waiting for? Ignoring Ecma, just adding code to WebKit
> doesn't make a cross-browser standard. Never mind Firefox (we'll do
> something soon enough to match). What about IE?
>

Given that we've missed IE9, we're talking about IE10 at the earliest.  If
history is a guide (which it might not be), that means we're talking about
something 2 years in the future.  If they're interested in supporting these
use cases, these APIs will (hopefully!) be long-stable by then.

It seems to me we (whatwg members, w3c members; browser vendors in general)
> need something more than IDL in the way of a spec.
>

Ok.  I'll write up a spec later today.

On Mon, Feb 14, 2011 at 12:01 PM, Shabsi Walfish  wrote:

> On Mon, Feb 14, 2011 at 11:31 AM, Adam Barth  wrote:
>
>> I'm not sure that's possible without either allowing the API to block for
>> arbitrary periods of time or to fail.  Assuming we want a non-blocking,
>> non-failing API, we can't make any guarantees about the quality of the
>> randomness.  In that sense, crypto.getRandomValues is "best effort."
>>
>
> I don't think its necessary to use "best effort" if you want something that
> is effectively non-blocking... what you need to do is preemptively gather a
> _small_ amount of real entropy on startup (say, 160 bits worth) and then use
> a cryptographic PRNG to generate whatever you need based on that seed... the
> PRNG would be pretty darn fast, so you wouldn't have to block forever after.
> Only the initial seeding needs to be done via a call to the OS that might
> block, and if that can be done asynchronously at startup time odds are good
> it will be a non-issue on most all platforms. Whatever you do, my advice is
> to combine entropy in the seed pool via XOR (assuming you do any entropy
> combining), since various combinations of append/prepend/etc. always lead to
> problems.
>

Right, but that approach does not provide any lower bounds on the quality of
the entropy.  If you keep running the PRNG, you'll eventually drain the
entropy pool.  It's an inescapable mathematical fact.  However, I agree that
it's a good best-effort design, and is precisely how arc4random works in Mac
OS X.


On Mon, Feb 14, 2011 at 12:15 PM, Mark S. Miller  wrote:

> Before posting on this thread, please subscribe at <
> https://mail.mozilla.org/listinfo/es-discuss> to es-discuss. The
> es-discuss list drops posts by non-subscribers, and thus seems to have
> dropped posts by Adam Barth and Shabsi Walfish that were sent after
> es-discuss was added to the thread. Adam and Shabsi, could you please
> subscribe and re-post? Thanks.
>

Apologies.  I'm subscribed to es-discuss under a different email address.
 I'll fix that shortly.


> As has already been discussed, since these issues are general EcmaScript
> issues, applying not just in the browser but in many places JavaScript is
> run (e.g., nodejs), I suggest that this be the last message on this thread
> cross-posted to whatwg. Unless someone has a reason for retaining whatwg in
> the addressee list, I will drop it from all my further postings on this
> thread.
>

Actually, that is precisely what we're discussing.  My suggestion is that we
do both: browsers implement a simple DOM-based API today that handles the
basic arc4random-like use case and TC39 go through whatever multi-month
(year?) process it likes and spec out whatever all-sing, all-dance crypto
library it likes.

Adam

Re: [whatwg] Cryptographically strong random numbers

[Mark S. Miller]

Everyone,

Before posting on this thread, please subscribe at <
https://mail.mozilla.org/listinfo/es-discuss> to es-discuss. The es-discuss
list drops posts by non-subscribers, and thus seems to have dropped posts by
Adam Barth and Shabsi Walfish that were sent after es-discuss was added to
the thread. Adam and Shabsi, could you please subscribe and re-post? Thanks.

As has already been discussed, since these issues are general EcmaScript
issues, applying not just in the browser but in many places JavaScript is
run (e.g., nodejs), I suggest that this be the last message on this thread
cross-posted to whatwg. Unless someone has a reason for retaining whatwg in
the addressee list, I will drop it from all my further postings on this
thread.


On Mon, Feb 14, 2011 at 12:01 PM, Shabsi Walfish  wrote:

>
>
> On Mon, Feb 14, 2011 at 11:31 AM, Adam Barth  wrote:
>
>> On Mon, Feb 14, 2011 at 8:31 AM, Mark S. Miller wrote:
>>
>>> On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth  wrote:
>>>
 That's a pretty long time horizon.  You're going to start discussing
 it in 2-4 months?  That seems a bit overwrought for what amounts to
 four lines of code.

>>>
>>> The committee meets once every two months. Between meetings, we discuss
>>> things on es-discuss, so please do.
>>>
>>> What are the four lines of code?
>>>
>>
>> http://trac.webkit.org/browser/trunk/Source/WebCore/page/Crypto.cpp
>>
>> On Mon, Feb 14, 2011 at 8:40 AM, Boris Zbarsky  wrote:
>>
>>>  On 2/14/11 11:31 AM, Mark S. Miller wrote:
>>>
  On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth >>> > wrote:

That's a pretty long time horizon.  You're going to start discussing
it in 2-4 months?  That seems a bit overwrought for what amounts to
four lines of code.

>>>
>>> For what it's worth, it's a lot more than 4 lines of code in Gecko,
>>> because we don't have an existing source of strong randomness in
>>> Spidermonkey.  It'd be about that much code in the DOM, where we could pass
>>> the buck to NSS, but for Spidermonkey it would take a good bit more work.
>>>
>>
>> Similarly, the WebKit implementation just passes the buck to the WTF
>> layer, which already knows how to fill a void* with n cryptographically
>> random bytes.  The implementation will be similarly trivial in most
>> applications that link with OpenSSL or NSS or that run on Mac, Linux, or
>> Windows.
>>
>> On Mon, Feb 14, 2011 at 10:05 AM, Brendan Eich 
>>  wrote:
>>
>>> On Feb 14, 2011, at 8:40 AM, Boris Zbarsky wrote:
>>> > On 2/14/11 11:31 AM, Mark S. Miller wrote:
>>> >> On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth >>  >> > wrote:
>>> >>
>>> >>That's a pretty long time horizon.  You're going to start
>>> discussing
>>> >>it in 2-4 months?  That seems a bit overwrought for what amounts to
>>> >>four lines of code.
>>> >
>>> > For what it's worth, it's a lot more than 4 lines of code in Gecko,
>>> because we don't have an existing source of strong randomness in
>>> Spidermonkey.  It'd be about that much code in the DOM, where we could pass
>>> the buck to NSS, but for Spidermonkey it would take a good bit more work.
>>>
>>> Not really. We use callback-style APIs to delegate such chores as l10n to
>>> the embedding, and the same can be done for randomness-hunting. It's just
>>> interfacing, or buck-passing -- but I'm still wondering what magical four
>>> lines of code provide useful lower bounds on bits of entropy in WebKit. Is
>>> this just non-interoperable delegation to the host OS?
>>>
>>
>> What's non-interoperable about filling an ArrayBuffer with random bytes?
>>  I'm not sure I understand your question.
>>
>> Adam, I like moving fast (but beware, that's how JS and the DOM were
>>> created), but we need a cross-browser spec of some kind, even if we all add
>>> crypto.getRandomValues quickly. The original y2k-buggy,
>>> cloned-from-java.util.Date JS Date object of 1995 required a lot of work for
>>> ES1 to remove OS dependencies that made for interop hell.
>>>
>>
>> In this case, the API is several order of magnitude simpler than Date.
>>  The choices to make roughly boil down to the name of the function, which
>> types to support, and what sorts of exceptions to throw in which error
>> cases.
>>
>>
>>> For a core language standard, we would want some kind of minimum quality
>>> guarantee on the randomness.
>>>
>>
>> I'm not sure that's possible without either allowing the API to block for
>> arbitrary periods of time or to fail.  Assuming we want a non-blocking,
>> non-failing API, we can't make any guarantees about the quality of the
>> randomness.  In that sense, crypto.getRandomValues is "best effort."
>>
>
> I don't think its necessary to use "best effort" if you want something that
> is effectively non-blocking... what you need to do is preemptively gather a
> _small_ amount of real entropy on startup (say, 160 bits worth) and then use
> a cryptographic PRNG to generate whatever y

Re: [whatwg] Cryptographically strong random numbers

[Brendan Eich]

On Feb 14, 2011, at 11:31 AM, Adam Barth wrote:

> What's non-interoperable about filling an ArrayBuffer with random bytes?  I'm 
> not sure I understand your question.

The question is what OSes fail to provide enough random bits these days.

This may just be a sanity-checking step (my sanity, at least; I lived through 
the great entropy hunt of 1995; 
http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html [link courtesy 
dwagner]).


> However, I'm disinclined to wait on the basic best-effort PRNG for that to 
> happen.

What would you be waiting for? Ignoring Ecma, just adding code to WebKit 
doesn't make a cross-browser standard. Never mind Firefox (we'll do something 
soon enough to match). What about IE?

It seems to me we (whatwg members, w3c members; browser vendors in general) 
need something more than IDL in the way of a spec.


> I added support for all the integer ArrayBuffer types, so getRandomBytes 
> isn't a particularly accurate name.

Ok, that seems fine (now that I have read your patch -- thanks for the link!).

/be

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

On Mon, Feb 14, 2011 at 8:31 AM, Mark S. Miller  wrote:

> On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth  wrote:
>
>> That's a pretty long time horizon.  You're going to start discussing
>> it in 2-4 months?  That seems a bit overwrought for what amounts to
>> four lines of code.
>>
>
> The committee meets once every two months. Between meetings, we discuss
> things on es-discuss, so please do.
>
> What are the four lines of code?
>

http://trac.webkit.org/browser/trunk/Source/WebCore/page/Crypto.cpp

On Mon, Feb 14, 2011 at 8:40 AM, Boris Zbarsky  wrote:

> On 2/14/11 11:31 AM, Mark S. Miller wrote:
>
>> On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth > > wrote:
>>
>>That's a pretty long time horizon.  You're going to start discussing
>>it in 2-4 months?  That seems a bit overwrought for what amounts to
>>four lines of code.
>>
>
> For what it's worth, it's a lot more than 4 lines of code in Gecko, because
> we don't have an existing source of strong randomness in Spidermonkey.  It'd
> be about that much code in the DOM, where we could pass the buck to NSS, but
> for Spidermonkey it would take a good bit more work.


Similarly, the WebKit implementation just passes the buck to the WTF layer,
which already knows how to fill a void* with n cryptographically random
bytes.  The implementation will be similarly trivial in most applications
that link with OpenSSL or NSS or that run on Mac, Linux, or Windows.

On Mon, Feb 14, 2011 at 10:05 AM, Brendan Eich  wrote:

> On Feb 14, 2011, at 8:40 AM, Boris Zbarsky wrote:
> > On 2/14/11 11:31 AM, Mark S. Miller wrote:
> >> On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth  >> > wrote:
> >>
> >>That's a pretty long time horizon.  You're going to start discussing
> >>it in 2-4 months?  That seems a bit overwrought for what amounts to
> >>four lines of code.
> >
> > For what it's worth, it's a lot more than 4 lines of code in Gecko,
> because we don't have an existing source of strong randomness in
> Spidermonkey.  It'd be about that much code in the DOM, where we could pass
> the buck to NSS, but for Spidermonkey it would take a good bit more work.
>
> Not really. We use callback-style APIs to delegate such chores as l10n to
> the embedding, and the same can be done for randomness-hunting. It's just
> interfacing, or buck-passing -- but I'm still wondering what magical four
> lines of code provide useful lower bounds on bits of entropy in WebKit. Is
> this just non-interoperable delegation to the host OS?
>

What's non-interoperable about filling an ArrayBuffer with random bytes?
 I'm not sure I understand your question.

Adam, I like moving fast (but beware, that's how JS and the DOM were
> created), but we need a cross-browser spec of some kind, even if we all add
> crypto.getRandomValues quickly. The original y2k-buggy,
> cloned-from-java.util.Date JS Date object of 1995 required a lot of work for
> ES1 to remove OS dependencies that made for interop hell.
>

In this case, the API is several order of magnitude simpler than Date.  The
choices to make roughly boil down to the name of the function, which types
to support, and what sorts of exceptions to throw in which error cases.


> For a core language standard, we would want some kind of minimum quality
> guarantee on the randomness.
>

I'm not sure that's possible without either allowing the API to block for
arbitrary periods of time or to fail.  Assuming we want a non-blocking,
non-failing API, we can't make any guarantees about the quality of the
randomness.  In that sense, crypto.getRandomValues is "best effort."

Obviously, a blocking API is in appropriate for the browser setting.
 There's certainly a place for failing randomness sources (e.g., analogous
to /dev/random versus /dev/urandom, although /dev/random is blocking rather
than failing).  The need just isn't as dire, in my view.  I'd certainly be
happy if ECMAScript came along in six months or a year with a nice
cryptographic library, including a variety of random generators (e.g.,
perhaps seedable, failing, and with algorithmic agility).  However, I'm
disinclined to wait on the basic best-effort PRNG for that to happen.


> Quick thought on the name: to avoid vagueness and the "why not wider int or
> even float element type" questions that have already come up, call the
> method getRandomBytes.
>

I added support for all the integer ArrayBuffer types, so getRandomBytes
isn't a particularly accurate name.

Adam

Re: [whatwg] Cryptographically strong random numbers

[Brendan Eich]

On Feb 14, 2011, at 8:40 AM, Boris Zbarsky wrote:

> On 2/14/11 11:31 AM, Mark S. Miller wrote:
>> On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth > > wrote:
>> 
>>That's a pretty long time horizon.  You're going to start discussing
>>it in 2-4 months?  That seems a bit overwrought for what amounts to
>>four lines of code.
> 
> For what it's worth, it's a lot more than 4 lines of code in Gecko, because 
> we don't have an existing source of strong randomness in Spidermonkey.  It'd 
> be about that much code in the DOM, where we could pass the buck to NSS, but 
> for Spidermonkey it would take a good bit more work.

Not really. We use callback-style APIs to delegate such chores as l10n to the 
embedding, and the same can be done for randomness-hunting. It's just 
interfacing, or buck-passing -- but I'm still wondering what magical four lines 
of code provide useful lower bounds on bits of entropy in WebKit. Is this just 
non-interoperable delegation to the host OS?

Adam, I like moving fast (but beware, that's how JS and the DOM were created), 
but we need a cross-browser spec of some kind, even if we all add 
crypto.getRandomValues quickly. The original y2k-buggy, 
cloned-from-java.util.Date JS Date object of 1995 required a lot of work for 
ES1 to remove OS dependencies that made for interop hell.

For a core language standard, we would want some kind of minimum quality 
guarantee on the randomness.

Quick thought on the name: to avoid vagueness and the "why not wider int or 
even float element type" questions that have already come up, call the method 
getRandomBytes.

/be

Re: [whatwg] Cryptographically strong random numbers

[Boris Zbarsky]

On 2/14/11 11:31 AM, Mark S. Miller wrote:

On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth mailto:w...@adambarth.com>> wrote:

That's a pretty long time horizon.  You're going to start discussing
it in 2-4 months?  That seems a bit overwrought for what amounts to
four lines of code.


For what it's worth, it's a lot more than 4 lines of code in Gecko, 
because we don't have an existing source of strong randomness in 
Spidermonkey.  It'd be about that much code in the DOM, where we could 
pass the buck to NSS, but for Spidermonkey it would take a good bit more 
work.


-Boris

Re: [whatwg] Cryptographically strong random numbers

[Mark S. Miller]

On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth  wrote:

> That's a pretty long time horizon.  You're going to start discussing
> it in 2-4 months?  That seems a bit overwrought for what amounts to
> four lines of code.
>

The committee meets once every two months. Between meetings, we discuss
things on es-discuss, so please do.

What are the four lines of code?



>
> In any case, I don't mean to discourage you.  Having nice crypto APIs
> available to JavaScript would be quite useful.
>
> Adam
>



-- 
Cheers,
--MarkM

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

On Sun, Feb 13, 2011 at 10:12 PM, Mark S. Miller  wrote:
> On Sun, Feb 13, 2011 at 6:37 PM, Boris Zbarsky  wrote:
>> On 2/13/11 8:22 PM, Adam Barth wrote:
>>> It seems likely that window.crypto will continue to grow more quality
>>> cryptographic APIs, not all of which will be appropriate at the
>>> ECMAScript level.
>>>
>>
>> Sure; the question is whether this _particular_ API would be more
>> appropriate at the language level.  Or more to the point, if the language
>> plans to grow it anyway, do we need two APIs for it?
>>
>> It's worth at least checking with the ES folks whether they plan to add a
>> API like this (something that fills in an array of bytes with
>> cryptographically strong random values) in any sort of short-term timeframe.
>
> Thanks for checking. The answer is yes. I'm scheduled to start a discussion
> of  at either the
> upcoming March or May meetings. Currently random-er is on the agenda for May
> but I may swap it into March. As you can tell, this page is currently only a
> placeholder.
>
> I have also talked just a bit with Shabsi Walfish, Ben Laurie, David Wagner,
> and Bill Frantz, all cc'ed, about the possibility of a real crypto API for
> EcmaScript. With the sole exception of randomness, I believe that we should
> handle this the same way we're handling i18n -- as a separate working group
> within tc39 (the EcmaScript committee) working on a separate standard
> library in a separate standards document. The reason to make an exception
> for random-er is that it's the only fundamental omission. Given a decent
> random-er, everything else can be done initially in JS.

That's a pretty long time horizon.  You're going to start discussing
it in 2-4 months?  That seems a bit overwrought for what amounts to
four lines of code.

In any case, I don't mean to discourage you.  Having nice crypto APIs
available to JavaScript would be quite useful.

Adam

Re: [whatwg] Cryptographically strong random numbers

[Mark S. Miller]

[+benl, +shabsi, +frantz, +daw]

On Sun, Feb 13, 2011 at 6:37 PM, Boris Zbarsky  wrote:

> On 2/13/11 8:22 PM, Adam Barth wrote:
>
>> It seems likely that window.crypto will continue to grow more quality
>> cryptographic APIs, not all of which will be appropriate at the
>> ECMAScript level.
>>
>
> Sure; the question is whether this _particular_ API would be more
> appropriate at the language level.  Or more to the point, if the language
> plans to grow it anyway, do we need two APIs for it?
>
> It's worth at least checking with the ES folks whether they plan to add a
> API like this (something that fills in an array of bytes with
> cryptographically strong random values) in any sort of short-term timeframe.
>

Thanks for checking. The answer is yes. I'm scheduled to start a discussion
of  at either the
upcoming March or May meetings. Currently random-er is on the agenda for May
but I may swap it into March. As you can tell, this page is currently only a
placeholder.

I have also talked just a bit with Shabsi Walfish, Ben Laurie, David Wagner,
and Bill Frantz, all cc'ed, about the possibility of a real crypto API for
EcmaScript. With the sole exception of randomness, I believe that we should
handle this the same way we're handling i18n -- as a separate working group
within tc39 (the EcmaScript committee) working on a separate standard
library in a separate standards document. The reason to make an exception
for random-er is that it's the only fundamental omission. Given a decent
random-er, everything else can be done initially in JS.



>
> -Boris
> ___
> es-discuss mailing list
> es-disc...@mozilla.org
>
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Cheers,
--MarkM

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

Fortunately, these APIs are quite simple (e.g., the implementation in
WebKit is a whole four lines of code) and having more than one way to
access good randomness isn't terribly costly.  Even if strong
randomness is a future aspiration for ECMAScript,
crypto.getRandomValues provides benefits today at low cost and is
probably still worth doing.

Adam


On Sun, Feb 13, 2011 at 8:26 PM, Brendan Eich  wrote:
> Yes, we aspire to standardize a good RBG as an "upgrade" to Math.random -- 
> obviously a new name would be needed, but with docs and evangelization we 
> would hope to steer people away from that old p.o.s. I copied from Java in 
> 1995 (quote unquote).
>
> See http://wiki.ecmascript.org/doku.php?id=strawman:random-er for the 
> mostly-aspirational page. As Boris says, this is a core language strawman 
> proposal, not something we want browser-only (think http://nodejs.org/).
>
> /be
>
>
> On Feb 13, 2011, at 6:37 PM, Boris Zbarsky wrote:
>
>> On 2/13/11 8:22 PM, Adam Barth wrote:
>>> It seems likely that window.crypto will continue to grow more quality
>>> cryptographic APIs, not all of which will be appropriate at the
>>> ECMAScript level.
>>
>> Sure; the question is whether this _particular_ API would be more 
>> appropriate at the language level.  Or more to the point, if the language 
>> plans to grow it anyway, do we need two APIs for it?
>>
>> It's worth at least checking with the ES folks whether they plan to add a 
>> API like this (something that fills in an array of bytes with 
>> cryptographically strong random values) in any sort of short-term timeframe.
>>
>> -Boris
>> ___
>> es-discuss mailing list
>> es-disc...@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
> ___
> es-discuss mailing list
> es-disc...@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

Re: [whatwg] Cryptographically strong random numbers

[Boris Zbarsky]

On 2/13/11 8:22 PM, Adam Barth wrote:

It seems likely that window.crypto will continue to grow more quality
cryptographic APIs, not all of which will be appropriate at the
ECMAScript level.


Sure; the question is whether this _particular_ API would be more 
appropriate at the language level.  Or more to the point, if the 
language plans to grow it anyway, do we need two APIs for it?


It's worth at least checking with the ES folks whether they plan to add 
a API like this (something that fills in an array of bytes with 
cryptographically strong random values) in any sort of short-term timeframe.


-Boris

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

On Sun, Feb 13, 2011 at 11:35 AM, David Bruant
 wrote:
> Le 05/02/2011 01:42, Adam Barth a écrit :
>> Several folks have asked for a cryptographically strong random number
>> generator in WebKit.  Our first approach was to make Math.random
>> cryptographically strong, but that approach has two major
>> disadvantages:
>>
>> 1) It's difficult for a web page to detect whether math.random is
>> actually cryptographically strong or whether it's a weak RNG.
>>
>> 2) Math.random is used in a number of popular JavaScript benchmarks.
>> Strengthening math.random to be cryptographically strong would slow
>> down these benchmarks.  Feel free to treat read this disadvantage as
>> "folks who don't care about cryptographic strength don't want to pay
>> the performance cost of cryptographic strength."
>>
>> Our second approach was to implement crypto.random, with the idea of
>> matching Firefox.  Unfortunately, Firefox does not appear to implement
>> crypto.random and instead just exposes a function that throws an
>> exception.  Additionally, crypto.random returns a string, which isn't
>> an ideal data type for randomness because we'd need to worry about
>> strange Unicode issues.
>>
>> Our third approach is to add a new cryptographically strong PRNG to
>> window.crypto (in the spirit of crypto.random) that return floating
>> point and integer random numbers:
>>
>> interface Crypto {
>>   Float32Array getRandomFloat32Array(in long length);
>>   Uint8Array getRandomUint8Array(in long length);
>> };
>>
>> These APIs use the ArrayBuffer types that already exist to service
>> APIs such as File and WebGL.  You can track the implementation of
>> these APIs via this WebKit bug:
>>
>> https://bugs.webkit.org/show_bug.cgi?id=22049
>>
>> Please let me know if you have any feedback.
> I am wondering if this topic is well-suited for the whatwg mailing-list.
> RNG has nothing to do with the web. It could be applied to the web or
> anything.
> This seems to be more of an ECMAScript issue. There is some drafty and
> incomplete work here :
> http://wiki.ecmascript.org/doku.php?id=strawman:random-er

Making Math.random cryptographically strong is a non-starter, as
discussed earlier in this thread.  Decoupling the Math.random state
for each global object is a good idea, but not related to making
cryptographically strong randomness available in the web platform.

> It might make sense to try to complete it with a proposal based on what
> have been said in that thread (especially the need of a different
> function than Math.random to not affect library using it with the
> overhead of cryptographically strong RNG).
> ES mailing-list: https://mail.mozilla.org/listinfo/es-discuss
>
> There are clear use cases, a couple of bugs related to the topic both at
> Mozilla and Webkit and some intention to work on having a
> cryptographically strong RNG in ECMAScript. Consequently, the process to
> have it standardized shouldn't be that different from what happens here.

It seems likely that window.crypto will continue to grow more quality
cryptographic APIs, not all of which will be appropriate at the
ECMAScript level.  For example, it's entirely likely we'll want to add
certificate generation and management APIs to window.crypto that
interact with the network stack (e.g., by making the generated
certificates function as HTTPS client certificates).

> It would also solve one of the problem cited in the WebKit bug which is
> that Web Workers have a limited access to the Window object features.
> However, if you add crypto to the ECMAScript global object, then your
> worker which has an ECMA(Java)Script context has an ECMA(Java)Script
> global object and since it's ECMAScript compliant (tell me if I'm wrong
> on that part), you have access to all ECMAScript features (String, Math,
> RegExp and the new crypto feature).

The WebWorker issue is independent of whether we define this API at
the DOM layer or at the ECMAScript layer.  For example, we could just
add the Crypto interface to WorkerContext to make this functionality
available to WebWorkers.

Adam

Re: [whatwg] Cryptographically strong random numbers

[David Bruant]

Le 05/02/2011 01:42, Adam Barth a écrit :
> Several folks have asked for a cryptographically strong random number
> generator in WebKit.  Our first approach was to make Math.random
> cryptographically strong, but that approach has two major
> disadvantages:
>
> 1) It's difficult for a web page to detect whether math.random is
> actually cryptographically strong or whether it's a weak RNG.
>
> 2) Math.random is used in a number of popular JavaScript benchmarks.
> Strengthening math.random to be cryptographically strong would slow
> down these benchmarks.  Feel free to treat read this disadvantage as
> "folks who don't care about cryptographic strength don't want to pay
> the performance cost of cryptographic strength."
>
> Our second approach was to implement crypto.random, with the idea of
> matching Firefox.  Unfortunately, Firefox does not appear to implement
> crypto.random and instead just exposes a function that throws an
> exception.  Additionally, crypto.random returns a string, which isn't
> an ideal data type for randomness because we'd need to worry about
> strange Unicode issues.
>
> Our third approach is to add a new cryptographically strong PRNG to
> window.crypto (in the spirit of crypto.random) that return floating
> point and integer random numbers:
>
> interface Crypto {
>   Float32Array getRandomFloat32Array(in long length);
>   Uint8Array getRandomUint8Array(in long length);
> };
>
> These APIs use the ArrayBuffer types that already exist to service
> APIs such as File and WebGL.  You can track the implementation of
> these APIs via this WebKit bug:
>
> https://bugs.webkit.org/show_bug.cgi?id=22049
>
> Please let me know if you have any feedback.
I am wondering if this topic is well-suited for the whatwg mailing-list.
RNG has nothing to do with the web. It could be applied to the web or
anything.
This seems to be more of an ECMAScript issue. There is some drafty and
incomplete work here :
http://wiki.ecmascript.org/doku.php?id=strawman:random-er
It might make sense to try to complete it with a proposal based on what
have been said in that thread (especially the need of a different
function than Math.random to not affect library using it with the
overhead of cryptographically strong RNG).
ES mailing-list: https://mail.mozilla.org/listinfo/es-discuss

There are clear use cases, a couple of bugs related to the topic both at
Mozilla and Webkit and some intention to work on having a
cryptographically strong RNG in ECMAScript. Consequently, the process to
have it standardized shouldn't be that different from what happens here.

It would also solve one of the problem cited in the WebKit bug which is
that Web Workers have a limited access to the Window object features.
However, if you add crypto to the ECMAScript global object, then your
worker which has an ECMA(Java)Script context has an ECMA(Java)Script
global object and since it's ECMAScript compliant (tell me if I'm wrong
on that part), you have access to all ECMAScript features (String, Math,
RegExp and the new crypto feature).

Cheers,

David

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

On Fri, Feb 11, 2011 at 5:08 PM, Cedric Vivier  wrote:
> On Sat, Feb 12, 2011 at 04:40, Adam Barth  wrote:
>>> Is there a specific reason for this limitation?
>>> Imho it should throw only for Float32Array and Float64Array since
>>> unbounded random floating numbers does not really make sense
>>> (including because of NaN and +inf -inf).
>> (...)
>> I went with a whitelist approach.  If there are other specific types
>> that you think we should whitelist, we can certainly do that.  Why
>> types, specifically, would you like to see supported?
>
> All integer types can have use cases imo so there is no reason to
> impose an articifial limitation [1] except for sanity-checking (floats
> does not make sense here), ie:
> Int8Array, UInt8Array, Int16Array, UInt16Array, Int32Array, UInt32Array

Done:
http://trac.webkit.org/changeset/78422

Adam

Re: [whatwg] Cryptographically strong random numbers

[Cedric Vivier]

On Sat, Feb 12, 2011 at 04:40, Adam Barth  wrote:
>> Is there a specific reason for this limitation?
>> Imho it should throw only for Float32Array and Float64Array since
>> unbounded random floating numbers does not really make sense
>> (including because of NaN and +inf -inf).
> (...)
> I went with a whitelist approach.  If there are other specific types
> that you think we should whitelist, we can certainly do that.  Why
> types, specifically, would you like to see supported?

All integer types can have use cases imo so there is no reason to
impose an articifial limitation [1] except for sanity-checking (floats
does not make sense here), ie:
Int8Array, UInt8Array, Int16Array, UInt16Array, Int32Array, UInt32Array

Regards,

[1] : artificial because typed arrays can be 'casted' anyways.

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

On Fri, Feb 11, 2011 at 1:13 PM, Glenn Maynard  wrote:
> On Fri, Feb 11, 2011 at 3:40 PM, Adam Barth  wrote:
>> In some cases, it's not possible to determine whether we'll be able to
>> get OS randomness until runtime.  For example, on Linux, if we don't
>> have permission to read /dev/urandom.
>
> You can have an exception, eg. INTERNAL_ERR or RUNTIME_ERR, for cases where
> the PRNG is normally expected to work but failed in a rare way at runtime.
> That's always possible in theory (eg. a read() from /dev/urandom returns an
> error), but is separate from feature testing since it can't be predicted,
> and it should be exceptionally rare.
>
>> Not all JavaScript engines have the ability to selectively disable DOM
>> APIs at runtime.
>
> If that's a concern, then all of the specs with the text I mentioned will
> have trouble.  I think either the convention of removing APIs at runtime
> should be expected and depended on by the specs (and used as consistently as
> is reasonable), or not used at all and those specs should be changed.

Regardless, the ability does not exist in JavaScriptCore.  If you'd
like to contribute a patch that makes it possible, I'm sure it would
be warmly received.

Adam

Re: [whatwg] Cryptographically strong random numbers

[Glenn Maynard]

On Fri, Feb 11, 2011 at 3:40 PM, Adam Barth  wrote:

> In some cases, it's not possible to determine whether we'll be able to
> get OS randomness until runtime.  For example, on Linux, if we don't
> have permission to read /dev/urandom.


You can have an exception, eg. INTERNAL_ERR or RUNTIME_ERR, for cases where
the PRNG is normally expected to work but failed in a rare way at runtime.
That's always possible in theory (eg. a read() from /dev/urandom returns an
error), but is separate from feature testing since it can't be predicted,
and it should be exceptionally rare.

Not all JavaScript engines have the ability to selectively disable DOM APIs
> at runtime.
>

If that's a concern, then all of the specs with the text I mentioned will
have trouble.  I think either the convention of removing APIs at runtime
should be expected and depended on by the specs (and used as consistently as
is reasonable), or not used at all and those specs should be changed.

-- 
Glenn Maynard

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

On Fri, Feb 11, 2011 at 4:32 AM, Glenn Maynard  wrote:
> On Fri, Feb 11, 2011 at 6:38 AM, Adam Barth  wrote:
>> Just to followup on this thread, I've landed this feature in WebKit.
>> I'm not sure whether it made it into tonight's nightly, but it should
>> be in a nightly shortly.  The IDL for the API is as follows:
>>
>> interface Crypto {
>>  void getRandomValues(in ArrayBufferView array) raises(DOMException);
>> };
>>
>> If the ArrayBufferView isn't a Uint8Array or if the user agent is
>> unable to obtain "true" randomness from the OS, getRandomValues throws
>> an exception (VALIDATION_ERR in the former case and NOT_SUPPORTED_ERR
>> in the latter case).
>
> Rather than raising NOT_SUPPORTED_ERR, would it be better to follow the
> example from other specs: to omit the function entirely if the feature is
> disabled?  (Specifically, "When support for a feature is disabled (e.g. as
> an emergency measure to mitigate a security problem, or to aid in
> development, or for performance reasons), user agents must act as if they
> had no support for the feature whatsoever, and as if the feature was not
> mentioned in this specification.")
>
> That's nicer for checking whether the function exists to check support.
> Otherwise, you have to make a dummy call to check support.  It also means
> you only need to check support in one way--since you'll need to check
> whether the function exists anyway.

In some cases, it's not possible to determine whether we'll be able to
get OS randomness until runtime.  For example, on Linux, if we don't
have permission to read /dev/urandom.  Not all JavaScript engines have
the ability to selectively disable DOM APIs at runtime.

On Fri, Feb 11, 2011 at 10:00 AM, Cedric Vivier  wrote:
> On Fri, Feb 11, 2011 at 19:38, Adam Barth  wrote:
>> Just to followup on this thread, I've landed this feature in WebKit.
>> I'm not sure whether it made it into tonight's nightly, but it should
>> be in a nightly shortly.
>
> Nice!
>
>> interface Crypto {
>>  void getRandomValues(in ArrayBufferView array) raises(DOMException);
>> };
>> If the ArrayBufferView isn't a Uint8Array , getRandomValues throws
>> an exception (VALIDATION_ERR
>
> Is there a specific reason for this limitation?
> Imho it should throw only for Float32Array and Float64Array since
> unbounded random floating numbers does not really make sense
> (including because of NaN and +inf -inf).
> However some use cases might prefer signed Int8Array or any other
> integer type and it doesn't change anything to the implementation :
> filling bytes to the ArrayBufferView's underlying ArrayBuffer).
>
> Like for instance you can do below in C to get random 32-bit numbers
> directly (though 'read' might very well get them one byte at a time
> from /dev/random) :
> int32_t random_32bit_integers[32];
> read(dev_random_fd, random_32bit_integers, sizeof(random_32bit_integers))

I went with a whitelist approach.  If there are other specific types
that you think we should whitelist, we can certainly do that.  Why
types, specifically, would you like to see supported?

Adam

Re: [whatwg] Cryptographically strong random numbers

[Cedric Vivier]

On Fri, Feb 11, 2011 at 19:38, Adam Barth  wrote:
> Just to followup on this thread, I've landed this feature in WebKit.
> I'm not sure whether it made it into tonight's nightly, but it should
> be in a nightly shortly.

Nice!


> interface Crypto {
>  void getRandomValues(in ArrayBufferView array) raises(DOMException);
> };
> If the ArrayBufferView isn't a Uint8Array , getRandomValues throws
> an exception (VALIDATION_ERR

Is there a specific reason for this limitation?
Imho it should throw only for Float32Array and Float64Array since
unbounded random floating numbers does not really make sense
(including because of NaN and +inf -inf).
However some use cases might prefer signed Int8Array or any other
integer type and it doesn't change anything to the implementation :
filling bytes to the ArrayBufferView's underlying ArrayBuffer).

Like for instance you can do below in C to get random 32-bit numbers
directly (though 'read' might very well get them one byte at a time
from /dev/random) :
int32_t random_32bit_integers[32];
read(dev_random_fd, random_32bit_integers, sizeof(random_32bit_integers))


Regards,

Re: [whatwg] Cryptographically strong random numbers

[Glenn Maynard]

On Fri, Feb 11, 2011 at 6:38 AM, Adam Barth  wrote:

> Just to followup on this thread, I've landed this feature in WebKit.
> I'm not sure whether it made it into tonight's nightly, but it should
> be in a nightly shortly.  The IDL for the API is as follows:
>
> interface Crypto {
>  void getRandomValues(in ArrayBufferView array) raises(DOMException);
> };
>
> If the ArrayBufferView isn't a Uint8Array or if the user agent is
> unable to obtain "true" randomness from the OS, getRandomValues throws
> an exception (VALIDATION_ERR in the former case and NOT_SUPPORTED_ERR
> in the latter case).
>

Rather than raising NOT_SUPPORTED_ERR, would it be better to follow the
example from other specs: to omit the function entirely if the feature is
disabled?  (Specifically, "When support for a feature is disabled (e.g. as
an emergency measure to mitigate a security problem, or to aid in
development, or for performance reasons), user agents must act as if they
had no support for the feature whatsoever, and as if the feature was not
mentioned in this specification.")

That's nicer for checking whether the function exists to check support.
Otherwise, you have to make a dummy call to check support.  It also means
you only need to check support in one way--since you'll need to check
whether the function exists anyway.

-- 
Glenn Maynard

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

Just to followup on this thread, I've landed this feature in WebKit.
I'm not sure whether it made it into tonight's nightly, but it should
be in a nightly shortly.  The IDL for the API is as follows:

interface Crypto {
 void getRandomValues(in ArrayBufferView array) raises(DOMException);
};

If the ArrayBufferView isn't a Uint8Array or if the user agent is
unable to obtain "true" randomness from the OS, getRandomValues throws
an exception (VALIDATION_ERR in the former case and NOT_SUPPORTED_ERR
in the latter case).

If the function doesn't throw an exception, the array is filled with
bytes obtained from a cryptographically strong PRNG seeded with "true"
randomness from the operating system.  Internally, WebKit uses RC4 as
the PRNG, but any cryptographically strong PRNG should work fine.

If there's interest, I can write up the above as a more formal
specification, but that seems like a bit of overkill given the
simplicity of the API.  Thanks for all your feedback.  It was quite
helpful.

Adam


On Fri, Feb 4, 2011 at 4:42 PM, Adam Barth  wrote:
> Several folks have asked for a cryptographically strong random number
> generator in WebKit.  Our first approach was to make Math.random
> cryptographically strong, but that approach has two major
> disadvantages:
>
> 1) It's difficult for a web page to detect whether math.random is
> actually cryptographically strong or whether it's a weak RNG.
>
> 2) Math.random is used in a number of popular JavaScript benchmarks.
> Strengthening math.random to be cryptographically strong would slow
> down these benchmarks.  Feel free to treat read this disadvantage as
> "folks who don't care about cryptographic strength don't want to pay
> the performance cost of cryptographic strength."
>
> Our second approach was to implement crypto.random, with the idea of
> matching Firefox.  Unfortunately, Firefox does not appear to implement
> crypto.random and instead just exposes a function that throws an
> exception.  Additionally, crypto.random returns a string, which isn't
> an ideal data type for randomness because we'd need to worry about
> strange Unicode issues.
>
> Our third approach is to add a new cryptographically strong PRNG to
> window.crypto (in the spirit of crypto.random) that return floating
> point and integer random numbers:
>
> interface Crypto {
>  Float32Array getRandomFloat32Array(in long length);
>  Uint8Array getRandomUint8Array(in long length);
> };
>
> These APIs use the ArrayBuffer types that already exist to service
> APIs such as File and WebGL.  You can track the implementation of
> these APIs via this WebKit bug:
>
> https://bugs.webkit.org/show_bug.cgi?id=22049
>
> Please let me know if you have any feedback.
>
> Thanks,
> Adam
>

Re: [whatwg] Cryptographically strong random numbers

[Nifty Egg Mitch]

On Sun, Feb 06, 2011 at 09:04:50AM +0100, Roger Hågensen wrote:
> Subject: Re: [whatwg] Cryptographically strong random numbers
> On 2011-02-06 04:54, Boris Zbarsky wrote:
> >On 2/5/11 10:22 PM, Roger Hågensen wrote:
> >
> >>This is just my oppinion but... If they need random number generation in
> >>their script to be cryptographically secure to be protected from another
> >>"spying" script...

Good reading -- thanks for the four below links:
> >You may want to read these:
> >
> >https://bugzilla.mozilla.org/show_bug.cgi?id=464071
> >https://bugzilla.mozilla.org/show_bug.cgi?id=475585
> >https://bugzilla.mozilla.org/show_bug.cgi?id=577512
> >https://bugzilla.mozilla.org/show_bug.cgi?id=322529
> >
>  [snip]
.
> Outch yeah, a nice mess there.
.
> 
> Math.random should be fixed (if implementations are bugged) so that
> cross-site tracking is not possible, besides that Math.random should
> just be a quick PRNG for generic use.

.
> I think it would be better to ensure it is not named "random" but
> "srandom" or "s_random" or "c_random" to avoid any confusion with
> Math.random
> How about "cryptrnd", anyone?
> 
> I'd hate to see a bunch of apps using cryptographically secure
> random numbers/data just because it was called "random",
> while in all likelyhood they'd be fine with Math.random instead.

Adding crypt* is a bit unsettling.
Adding randKnuthLCM, or rand.Algorithm
makes more sense.   To ignore that Knuth devoted
an entire chapter to random numbers is
naive.  See Chapter 3 of Vol 2. 

Perhaps someone at RSA could contribute
a list of algorithms that are worthy.

Re: [whatwg] Cryptographically strong random numbers

[Simon Pieters]

On Sat, 05 Feb 2011 17:18:05 +0100, Boris Zbarsky  wrote:


On 2/4/11 11:20 PM, Adam Barth wrote:

I'm not sure what else is exposed on Crypto, but having this available
to workers certainly make sense.


I was assuming that the crypto object in workers wouldn't have anything  
else on it, for now.


FWIW, The pattern for worker-specific interfaces is to prepend "Worker" to  
the interface name, i.e. "WorkerCrypto".


--
Simon Pieters
Opera Software

Re: [whatwg] Cryptographically strong random numbers

[Roger Hågensen]

On 2011-02-06 04:54, Boris Zbarsky wrote:

On 2/5/11 10:22 PM, Roger Hågensen wrote:


This is just my oppinion but... If they need random number generation in
their script to be cryptographically secure to be protected from another
"spying" script...
then they are doing it wrong. Use HTTPS, issue solved right?


No.  Why would it be?


Oh right! The flaw might even exist then as well, despite https and http 
not being mixable without warning.




I'm kinda intrigued about the people you've seen asking, and what 
exactly it is

they are coding if that is an issue. *laughs*


You may want to read these:

https://bugzilla.mozilla.org/show_bug.cgi?id=464071
https://bugzilla.mozilla.org/show_bug.cgi?id=475585
https://bugzilla.mozilla.org/show_bug.cgi?id=577512
https://bugzilla.mozilla.org/show_bug.cgi?id=322529


 [snip]



And don't forget that browsers like Chrome runs each tab in it's own
process, which means the PRNG may not share the seed at all with another
tab


Well, yes, that's another approach to the Math.random problems.  Do 
read the above bug reports.


-Boris



Outch yeah, a nice mess there.

Math.random should be fixed (if implementations are bugged) so that 
cross-site tracking is not possible, besides that Math.random should 
just be a quick PRNG for generic use.
The easiest fix (maybe this should be speced?) is that Math.random must 
have a separate seed per Tab/Page, this means that even an iframe would 
have a different seed than the parent page.
If this was done, then those bugs could all be fixed (apparently). And 
it wouldn't hurt to advise Mother or Mersenne or similar as a "minimum" 
PRNG.
Maybe seed should be speced in regards to tabs/pages etc, would this 
fall under WHATWG or the JS group?


But anyway, those bugs does not need actual crypto quality PRNG, so it's 
a shame their fixing is hampered by a "fix vs new feature" discussion.

I can't help but see these two "issues" as completely separate.
1. Fix the seeding of Math.random for tabs/pages so cross-site tracking 
is not possible.
2. Add Math.srandom or Crypto.random or Window.random a cryptographic 
PRNG data generator (which could map to OS API or even RNG Hardware).



Hmm. What of the name of this thing?
I think it would be better to ensure it is not named "random" but 
"srandom" or "s_random" or "c_random" to avoid any confusion with 
Math.random

How about "cryptrnd", anyone?

I'd hate to see a bunch of apps using cryptographically secure random 
numbers/data just because it was called "random",

while in all likelyhood they'd be fine with Math.random instead.


--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/

Re: [whatwg] Cryptographically strong random numbers

[Roger Hågensen]

On 2011-02-06 05:07, Cedric Vivier wrote:

On Sun, Feb 6, 2011 at 11:34, Roger Hågensen  wrote:

But getRandomValues(in ArrayBufferView data) seem to indicate that each byte
(value) is random, limited to an array of 8bit data?.

In the context of typed arrays, a value depends of the type of the
ArrayBufferView. ArrayBufferView are interchangable using the same
ArrayBuffer (the actual underlying bytes).
Passing an Uint8Array will give you random Uint8 values at each index
of the array, passing an Int32Array will give you random Int32 values
at each index of the array as well.


Ah ok, so just fill the buffer/destination with random data. That sounds 
as good as and as flexible as one possibly can get.



--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/

Re: [whatwg] Cryptographically strong random numbers

[Glenn Maynard]

On Sat, Feb 5, 2011 at 11:07 PM, Cedric Vivier  wrote:

> read(FD("/dev/random"), PTR(arraybufferview->data),
> arraybufferview->byteLength)
>

More accurately, /dev/urandom, since this is a synchronous API that
shouldn't block.  This should be made explicit if this gets specced.

I thought about suggesting a /dev/random-like interface earlier--one which
reads from a real, blocking entropy source (like /dev/random) with an async
API.  However, on examination /dev/urandom is apparently good enough even
for ssh-keygen, so I'm guessing that's unnecessary.  (It could also cause
other problems, eg. allowing webpages to flush a user's kernel's entropy
buffer and causing separate pages to compete for entropy data.)

-- 
Glenn Maynard

Re: [whatwg] Cryptographically strong random numbers

[Cedric Vivier]

On Sun, Feb 6, 2011 at 11:34, Roger Hågensen  wrote:
> But getRandomValues(in ArrayBufferView data) seem to indicate that each byte
> (value) is random, limited to an array of 8bit data?.

In the context of typed arrays, a value depends of the type of the
ArrayBufferView. ArrayBufferView are interchangable using the same
ArrayBuffer (the actual underlying bytes).
Passing an Uint8Array will give you random Uint8 values at each index
of the array, passing an Int32Array will give you random Int32 values
at each index of the array as well.

Technically the implementation is the same for any integer array :
filling the underlying array buffer (bytes) with random data, eg :

read(FD("/dev/random"), PTR(arraybufferview->data), arraybufferview->byteLength)


Regards,

Re: [whatwg] Cryptographically strong random numbers

[Boris Zbarsky]

On 2/5/11 10:22 PM, Roger Hågensen wrote:

The "bad script" is already inside the house anyway, but just in the
other room right?


Whatever that means.


This is just my oppinion but... If they need random number generation in
their script to be cryptographically secure to be protected from another
"spying" script...
then they are doing it wrong. Use HTTPS, issue solved right?


No.  Why would it be?


I'm kinda intrigued about the people you've seen asking, and what exactly it is
they are coding if that is an issue. *laughs*


You may want to read these:

https://bugzilla.mozilla.org/show_bug.cgi?id=464071
https://bugzilla.mozilla.org/show_bug.cgi?id=475585
https://bugzilla.mozilla.org/show_bug.cgi?id=577512
https://bugzilla.mozilla.org/show_bug.cgi?id=322529

and then you'll know everything I know about the problem.  ;)


Besides, isn't there several things (by WHATWG even) that prevents such
spying or even makes it impossible?


Do read the above bug reports.


But with the multithreaded and multicore CPU's, clock variations, and so
on, trying to exploit the pattern in say a Mersienne Twister PRNG


Which is a heck of a lot harder to guess than the PRNG Math.random 
actually uses in Gecko, fwiw.



by pulling lots of random numbers
would either A. not work or B. cause a suspicious 100% cpu use on a core.


Suspicious to whom?  Most users don't watch their CPU usage; they have 
better things to do with their time!



And don't forget that browsers like Chrome runs each tab in it's own
process, which means the PRNG may not share the seed at all with another
tab


Well, yes, that's another approach to the Math.random problems.  Do read 
the above bug reports.


-Boris

Re: [whatwg] Cryptographically strong random numbers

[Roger Hågensen]

On 2011-02-05 11:10, Adam Barth wrote:

On Fri, Feb 4, 2011 at 9:00 PM, Cedric Vivier  wrote:

getRandomValues(in ArrayBufferView data)
Fills a typed array with a cryptographically strong sequence of random values.
The length of the array determines how many cryptographically strong
random values are produced.


We had same discussion when defining readPixels API in WebGL.

Advantages :
1) this allows to reuse the same array over and over when necessary,
or circular buffer, instead of trashing the GC with new allocations
everytime one wants new random bytes.
2) this allows to fill any integer array directly (Float*Array might
need more specification here though as Boris pointed out - could be
disallowed initially)
3) this avoids exposing N methods for every type and makes refactoring
simpler (changing the array type does not require changing the
function call)

(and also better matches most existing crypto APIs in other languages
that are also given an array to fill rather than returning an array)

Oh, that's very cool.  Thanks.

Adam


I must say I like this as well. Having used RandomData(*buffer,length) 
in PureBasic makes more sense to me (then again I like procedural 
unmanaged programming with a sprinkle of ASM and API stuff so...)


But getRandomValues(in ArrayBufferView data) seem to indicate that each 
byte (value) is random, limited to an array of 8bit data?.

Now if that is the intention then that's fine.

But wouldn't getRandomData(in ArrayBufferView data) be the ideal? As 
there could be from 8bit of random data to whatever the max size of an 
array is in steps of 8bits (and you can always mask/truncate by hand for 
exact bits)


But other than that little nitbit, filling an array/buffer instead of 
returning one? Good idea!



--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/

Re: [whatwg] Cryptographically strong random numbers

[Roger Hågensen]

On 2011-02-06 03:34, Boris Zbarsky wrote:
The context in which I've seen people ask for cryptographically secure 
Math.random are cases where one script can tell what random numbers 
another script got by examining the sequence of random numbers it's 
getting itself.  But I was never told what that "other script" was 
doing, only that it wanted its random numbers to be unguessable.


Hmm! A hostile script/cross-site exploit?
But if a script is running "that close" to another script, isn't the 
guessing of the other script's random numbers the least of your worries?
The "bad script" is already inside the house anyway, but just in the 
other room right?


It kinda reminds me of Raymond Chen at MicroSoft. Just Google the 
followingsite:msdn.com It rather involved being on the other 
side of this airtight hatchway

Kind reminds me of some of those stories.
I assume they are worried about two tabs or an iframe in a page, and a 
"bad" script is trying to figure out the random numbers another script has.


This is just my oppinion but... If they need random number generation in 
their script to be cryptographically secure to be protected from another 
"spying" script...
then they are doing it wrong. Use HTTPS, issue solved right? I'm kinda 
intrigued about the people you've seen asking, and what exactly it is 
they are coding if that is an issue. *laughs*
Besides, isn't there several things (by WHATWG even) that prevents such 
spying or even makes it impossible?


I have yet to hear of any actual panic regarding this, the same "issue" 
is theoretically know with EXE's as well.
But with the multithreaded and multicore CPU's, clock variations, and so 
on, trying to exploit the pattern in say a Mersienne Twister PRNG by 
pulling lots of random numbers

would either A. not work or B. cause a suspicious 100% cpu use on a core.
And don't forget that browsers like Chrome runs each tab in it's own 
process, which means the PRNG may not share the seed at all with another 
tab (I'm guessing pretty surely that each tab HAS it's own seed).

Besides, social engineering has a much higher success rate than this so...

Would be nice if some crypto/security experts popped their heads in 
about now though, in particular about the float question in previous 
posts :)



--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/

Re: [whatwg] Cryptographically strong random numbers

[Boris Zbarsky]

On 2/5/11 9:08 PM, Roger Hågensen wrote:

If you really wanted a float, and really wanted minimal issue with float
behavior then creating a random um... mantissa.?... "should" allow a
better 0.0 to 1.0 than the divide shown further up.


That's the thing.  The valid mantissas for IEEE floats are nonuniformly 
distributed on the unit interval.  So you don't want to generate all 
mantissas with equal probability... or something.  So yeah, the key 
issue here is defining what one means by "a random float" and what one 
wants from it.


I suspect that most people who use random numbers on the web don't stop 
to think about any of that, though; I just always hope whatever they're 
doing with them is unimportant enough that the issues with their 
randomness sources won't matter...



I suspect that they may not want secure random numbers as much as they
might want secure random data for key generation.


That makes sense, and doesn't need floats.  I don't think we need use 
cases for the uint8 version of a good random-number generator.  There 
are lots of those.  ;)


The context in which I've seen people ask for cryptographically secure 
Math.random are cases where one script can tell what random numbers 
another script got by examining the sequence of random numbers it's 
getting itself.  But I was never told what that "other script" was 
doing, only that it wanted its random numbers to be unguessable.



Couldn't the Uint8Array mostly piggyback on whatever certificate code
the browser has? Which is either done by the browser or by a OS API.
In fact leaving the sourcing of the data not specified (besides that it
need to be cryptographically secure/random) because it would be
implementation agnostic and hence future proof.


That's the general idea, yes.

-Boris

Re: [whatwg] Cryptographically strong random numbers

[Roger Hågensen]

On 2011-02-05 17:37, Boris Zbarsky wrote:

On 2/5/11 1:55 AM, Roger Hågensen wrote:

On 2011-02-05 04:39, Boris Zbarsky wrote:

In general, I suspect creating a good definition for the float version
of this API may be hard.


Not really, usually it is a number from 0.0 to 1.0, which would map to
say the same as 0 to whatever max 64bit is.


Those aren't the same thing, though.



(see further down)


Depending on the implementation, the simplest is just to do (pseudocode)
float=Random(0,$)/$


That gives you non-uniform distribution, no?  In particular, the 
conversion to float will lead to rounding, and different rounding in 
different parts of the range.  So for example if the result of 
Random() is 2^{50} you will get the same float as you would for 
everything up through 2^{50} + 2^{25} or so (assuming single-precision 
floats), whereas around 0 the range of values that actually ends up 0 
is only about 2^18 because you can end up with subnormals, right?




(see even further down)


And yes, float issues of rounding and "almost correct but not quite"
will also be an issue here.


Indeed; I'm not sure how you can say creating a good definition is 
"not really hard" while leaving this problem unsolved in the "not 
really hard" case... ;)




(here we go)

If you really wanted a float, and really wanted minimal issue with float 
behavior then creating a random um... mantissa.?... "should" allow a 
better 0.0 to 1.0 than the divide shown further up.

I have never tested that though.



Float random does not make much sense in crypto.


Indeed.

The question is, do people want cryptographically secure random 
numbers for crypto, or something else?  As you say, we need to 
understand the use cases.


-Boris



I suspect that they may not want secure random numbers as much as they 
might want secure random data for key generation.

So a uint8 array of say 128bytes would be the same as a 1024bit key.

I can see for example a key being generated like this in a app to 
generate a key for a server to use.
I seem to recall that StartSSL.com (I think I've mentioned them before 
here?) uses a server side key generation for the private key to be used 
with certificates.
With something like Uint8Array getRandomUint8Array(in long length); the 
key could be generated client side,

which would mean less server load and faster generation of the key as well.

That's one possible use case I can think of off the top of my head.
The other would be binary passwords or passphrases, but I can't recall 
anyone using them (or wanting to use them, besides me)... so... *shrug*...
A key for file/data encryption on the other hand would probably be the 
most popular use initially, but I'm just guessing here.


Couldn't the Uint8Array mostly piggyback on whatever certificate code 
the browser has? Which is either done by the browser or by a OS API.
In fact leaving the sourcing of the data not specified (besides that it 
need to be cryptographically secure/random) because it would be 
implementation agnostic and hence future proof.



So a few possible use cases here, but does anyone have any other use 
cases than the following?:


*Clientside keygeneration for certificate creation instead of server side.
Can't think of anything negative here, rather I'm surprised this hasn't 
been possible previously.
Maybe this could get rid of those damn Java apps that all Banks insist 
on using to log in securely?


* Binary password/passphrase.
Would be hell to remember, so this would be password manager controlled.
The other issue is how many sites would accept full binary bytes as 
passwords/phrases?


* Key for file/data encryption.
Client side is kinda silly here, but server side or "export" of data 
might benefit from this.

But wouldn't exposing more of the SSL stuff also make sense?


--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/

Re: [whatwg] Cryptographically strong random numbers

[Dirk-Willem van Gulik]

On 5 Feb 2011, at 16:37, Boris Zbarsky wrote:

> The question is, do people want cryptographically secure random numbers for 
> crypto, or something else?  As you say, we need to understand the use cases.

If you want to use them for crypto - you need to have a very clear contract. 
Otherwise they are may well be very usable - but not for crypto. 

I.e. be very clear if you desire to follow the recommendation in something like 
FIPS P 800-90* or passes the various tests in FIPS SP 800-22 (or some other 
recognised equivalent).

As IMHO 'Then and only then' can one use it for crypto without worry. As 
otherwise it is just strong randomness.

Thanks,

Dw

*: http://csrc.nist.gov/publications/PubsSPs.html

Re: [whatwg] Cryptographically strong random numbers

[Boris Zbarsky]

On 2/5/11 1:55 AM, Roger Hågensen wrote:

On 2011-02-05 04:39, Boris Zbarsky wrote:

In general, I suspect creating a good definition for the float version
of this API may be hard.


Not really, usually it is a number from 0.0 to 1.0, which would map to
say the same as 0 to whatever max 64bit is.


Those aren't the same thing, though.


Depending on the implementation, the simplest is just to do (pseudocode)
float=Random(0,$)/$


That gives you non-uniform distribution, no?  In particular, the 
conversion to float will lead to rounding, and different rounding in 
different parts of the range.  So for example if the result of Random() 
is 2^{50} you will get the same float as you would for everything up 
through 2^{50} + 2^{25} or so (assuming single-precision floats), 
whereas around 0 the range of values that actually ends up 0 is only 
about 2^18 because you can end up with subnormals, right?



And yes, float issues of rounding and "almost correct but not quite"
will also be an issue here.


Indeed; I'm not sure how you can say creating a good definition is "not 
really hard" while leaving this problem unsolved in the "not really 
hard" case... ;)



Float random does not make much sense in crypto.


Indeed.

The question is, do people want cryptographically secure random numbers 
for crypto, or something else?  As you say, we need to understand the 
use cases.


-Boris

Re: [whatwg] Cryptographically strong random numbers

[Boris Zbarsky]

On 2/4/11 11:20 PM, Adam Barth wrote:

I'm not sure what else is exposed on Crypto, but having this available
to workers certainly make sense.


I was assuming that the crypto object in workers wouldn't have anything 
else on it, for now.


-Boris

Re: [whatwg] Cryptographically strong random numbers

[Dirk-Willem van Gulik]

On 5 Feb 2011, at 00:42, Adam Barth wrote:

...
> cryptographically strong PRNG

Would it be useful to very clearly qualify this - and put a boundary around 
this potentially unsolvable problem ? I.e. a pseudo random generator which 
meeds to exceeds requirements X, Y and Z from NIST SP 800-90 or which passes 
critera such-and-such from NIST 800-22 ?

Just so that both the contract to the user is clear - and it is measurable ? 
And it is clear what it can be used for.

> Our third approach is to add a new cryptographically strong PRNG to
> window.crypto (in the spirit of crypto.random) that return floating
> point and integer random numbers:
> 
> interface Crypto {
> Float32Array getRandomFloat32Array(in long length);
> Uint8Array getRandomUint8Array(in long length);
> };

A Uint8 makes perfect sense - but why the float ? What crypto uses this ? And 
exactly what do then the various +- infitiy/NaNs mean ?

Dw

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

On Fri, Feb 4, 2011 at 9:00 PM, Cedric Vivier  wrote:
> On Sat, Feb 5, 2011 at 08:42, Adam Barth  wrote:
>> interface Crypto {
>>  Float32Array getRandomFloat32Array(in long length);
>>  Uint8Array getRandomUint8Array(in long length);
>> };
>
> I think the API would be more flexible and more future-proof defined as :
>
> interface Crypto {
>    void getRandomValues(in ArrayBufferView data);
> }
>
> getRandomValues(in ArrayBufferView data)
> Fills a typed array with a cryptographically strong sequence of random values.
> The length of the array determines how many cryptographically strong
> random values are produced.
>
>
> We had same discussion when defining readPixels API in WebGL.
>
> Advantages :
> 1) this allows to reuse the same array over and over when necessary,
> or circular buffer, instead of trashing the GC with new allocations
> everytime one wants new random bytes.
> 2) this allows to fill any integer array directly (Float*Array might
> need more specification here though as Boris pointed out - could be
> disallowed initially)
> 3) this avoids exposing N methods for every type and makes refactoring
> simpler (changing the array type does not require changing the
> function call)
>
> (and also better matches most existing crypto APIs in other languages
> that are also given an array to fill rather than returning an array)

Oh, that's very cool.  Thanks.

Adam

Re: [whatwg] Cryptographically strong random numbers

[Roger Hågensen]

On 2011-02-05 04:39, Boris Zbarsky wrote:

On 2/4/11 7:42 PM, Adam Barth wrote:

interface Crypto {
   Float32Array getRandomFloat32Array(in long length);
   Uint8Array getRandomUint8Array(in long length);
};


The Uint8Array version is good; let's do that.

For the other, what does it mean to return a random 32-bit float?  Is 
NaN allowed?  Different NaNs?  -0?  Infinity or -Infinity?  Subnormal 
values?


Looking at the webkit impl you linked to and my somewhat-old webkit 
checkout, it looks like the proposed impl returns something in the 
range [0, 1), right?  (Though if so, I'm not sure why the &0xFF bit is 
needed in integer implementation.)  It also returns something that's 
not uniformly distributed in that range, at least on Mac and sometimes 
on Windows (in the sense that there are intervals inside [0, 1) that 
have 0 probability of having a number inside that interval returned).


In general, I suspect creating a good definition for the float version 
of this API may be hard.


Not really, usually it is a number from 0.0 to 1.0, which would map to 
say the same as 0 to whatever max 64bit is.
Depending on the implementation, the simplest is just to do 
(pseudocode)   float=Random(0,$)/$

A Float64Array getRandomFloat64Array() would also be interesting.
In fact the 32bit and 64bit and uint8 could all be generated from the 
same random data source, just presented differently, uint8 would be the 
"raw"'est though,

and 32bit float is pretty much just truncation of a 64bit float.
But with either float there would never be NaN -0 or Infinity or 
-Infinity. Only the range 0.0 to 1.0 must be returned.
And yes, float issues of rounding and "almost correct but not quite" 
will also be an issue here.


Float random does not make much sense in crypto. In normal random stuff 
I do see it usefull but not crypto.
Then again, look at the potential use cases out there. Does any use 
float? Or do they all use uint/raw?

If they do not use float then just do not include float at all in crypto.

Right now I can only see random floats being of use in 
audio/video/graphics/games/input/output/etc. But not in crypto. (the 
only "key" and "nonce" data/values I've ever seen has been raw/uint or 
an integer or string. never a float)



--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/

Re: [whatwg] Cryptographically strong random numbers

[Tom Mitchell]

On Fri, Feb 4, 2011 at 9:00 PM, Cedric Vivier  wrote:
> Hi,
>
> On Sat, Feb 5, 2011 at 08:42, Adam Barth  wrote:
>> interface Crypto {
>>  Float32Array getRandomFloat32Array(in long length);
>>  Uint8Array getRandomUint8Array(in long length);
>> };
>
> I think the API would be more flexible and more future-proof

Future proof -- that is defined as :
>
> interface Crypto {
>void getRandomValues(in ArrayBufferView data);
> }
>
> getRandomValues(in ArrayBufferView data)
> Fills a typed array with a cryptographically strong sequence of random values.
> The length of the array determines how many cryptographically strong
> random values are produced.
>
>
> We had same discussion when defining readPixels API in WebGL.
>
> Advantages :
> 1) this allows to reuse the same array over and over when necessary,
> or circular buffer, instead of trashing the GC with new allocations
> everytime one wants new random bytes.
> 2) this allows to fill any integer array directly (Float*Array might
> need more specification here though as Boris pointed out - could be
> disallowed initially)
> 3) this avoids exposing N methods for every type and makes refactoring
> simpler (changing the array type does not require changing the
> function call)
>
> (and also better matches most existing crypto APIs in other languages
> that are also given an array to fill rather than returning an array)
>
>
> Regards,
>


Future proof is hard.
Seed management is critical and
different tools apply better or worse
depending on the statistics of the
values being requested.

There is some reading worth looking at on
the LavaRand site. http://lavarand.com/

Any implementation for Strong random or pseudo
random numbers should permit hardware assist.

Another option is that a site might supply its own
numbers or seeds with a browser script or php or other
tool.

Another option is to fetch an array from "localhost://bin/randint16"

A good generator is hard to code   An interface
that permits improvements and connections near or far to
hardware assist is a good thing.

-- 

                      T o m   M i t c h e l l
                    mitch-at-niftyegg-dot-com
"My lifetime goal is to be the kind of person my dogs think I am."

Re: [whatwg] Cryptographically strong random numbers

[Cedric Vivier]

Hi,

On Sat, Feb 5, 2011 at 08:42, Adam Barth  wrote:
> interface Crypto {
>  Float32Array getRandomFloat32Array(in long length);
>  Uint8Array getRandomUint8Array(in long length);
> };

I think the API would be more flexible and more future-proof defined as :

interface Crypto {
void getRandomValues(in ArrayBufferView data);
}

getRandomValues(in ArrayBufferView data)
Fills a typed array with a cryptographically strong sequence of random values.
The length of the array determines how many cryptographically strong
random values are produced.


We had same discussion when defining readPixels API in WebGL.

Advantages :
1) this allows to reuse the same array over and over when necessary,
or circular buffer, instead of trashing the GC with new allocations
everytime one wants new random bytes.
2) this allows to fill any integer array directly (Float*Array might
need more specification here though as Boris pointed out - could be
disallowed initially)
3) this avoids exposing N methods for every type and makes refactoring
simpler (changing the array type does not require changing the
function call)

(and also better matches most existing crypto APIs in other languages
that are also given an array to fill rather than returning an array)


Regards,

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

On Fri, Feb 4, 2011 at 8:18 PM, Boris Zbarsky  wrote:
> On 2/4/11 11:01 PM, Boris Zbarsky wrote:
>> Sounds like a plan. I'll see about getting this to happen in Gecko too.
>
> One other thing.  If we hang this off Crypto, we should expose Crypto in
> workers, right?

I'm not sure what else is exposed on Crypto, but having this available
to workers certainly make sense.

Adam

Re: [whatwg] Cryptographically strong random numbers

[Boris Zbarsky]

On 2/4/11 11:01 PM, Boris Zbarsky wrote:

Sounds like a plan. I'll see about getting this to happen in Gecko too.


One other thing.  If we hang this off Crypto, we should expose Crypto in 
workers, right?


-Boris

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

On Fri, Feb 4, 2011 at 8:01 PM, Boris Zbarsky  wrote:
>> Most operating systems provide strong sources of randomness that can
>> be used to seed cryptographic PRNGs.  I'd be inclined to recommend
>> that folks use that sort of "truly random" seed.
>
> That sounds good to me.
>
>> Given this feedback, we'll probably start off with the Uint8Array version.
>
> Sounds like a plan.  I'll see about getting this to happen in Gecko too.

Great.  Thanks Boris.

Adam

Re: [whatwg] Cryptographically strong random numbers

[Boris Zbarsky]

Most operating systems provide strong sources of randomness that can
be used to seed cryptographic PRNGs.  I'd be inclined to recommend
that folks use that sort of "truly random" seed.


That sounds good to me.


Given this feedback, we'll probably start off with the Uint8Array version.


Sounds like a plan.  I'll see about getting this to happen in Gecko too.

-Boris

Re: [whatwg] Cryptographically strong random numbers

[Adam Barth]

On Fri, Feb 4, 2011 at 7:39 PM, Boris Zbarsky  wrote:
> On 2/4/11 7:42 PM, Adam Barth wrote:
>> interface Crypto {
>>   Float32Array getRandomFloat32Array(in long length);
>>   Uint8Array getRandomUint8Array(in long length);
>> };
>
> The Uint8Array version is good; let's do that.
>
> For the other, what does it mean to return a random 32-bit float?  Is NaN
> allowed?  Different NaNs?  -0?  Infinity or -Infinity?  Subnormal values?

Those are good questions.

> Looking at the webkit impl you linked to and my somewhat-old webkit
> checkout, it looks like the proposed impl returns something in the range [0,
> 1), right?  (Though if so, I'm not sure why the &0xFF bit is needed in
> integer implementation.)  It also returns something that's not uniformly
> distributed in that range, at least on Mac and sometimes on Windows (in the
> sense that there are intervals inside [0, 1) that have 0 probability of
> having a number inside that interval returned).

That patch hasn't been reviewed yet.  Think of it more of a proof-of-concept.

> In general, I suspect creating a good definition for the float version of
> this API may be hard.

The main use cases I've heard are for the int version.  Presumable
someone who wants random floats can compute them given integer
randomness.

> One other thing that perhaps needs to be defined is seeding.  In particular,
> just because you have a cryptographically strong PRNG doesn't mean that you
> can't always seed it with 0 on pageload or something dumb like that.  Should
> we require that the seed be truly random or some such?  Or at least not
> fixed?  Should web pages be able to reseed this generator (at least for the
> web page in question; obviously not for others)?

Most operating systems provide strong sources of randomness that can
be used to seed cryptographic PRNGs.  I'd be inclined to recommend
that folks use that sort of "truly random" seed.

Given this feedback, we'll probably start off with the Uint8Array version.

Thanks,
Adam

Re: [whatwg] Cryptographically strong random numbers

[Boris Zbarsky]

On 2/4/11 7:42 PM, Adam Barth wrote:

interface Crypto {
   Float32Array getRandomFloat32Array(in long length);
   Uint8Array getRandomUint8Array(in long length);
};


The Uint8Array version is good; let's do that.

For the other, what does it mean to return a random 32-bit float?  Is 
NaN allowed?  Different NaNs?  -0?  Infinity or -Infinity?  Subnormal 
values?


Looking at the webkit impl you linked to and my somewhat-old webkit 
checkout, it looks like the proposed impl returns something in the range 
[0, 1), right?  (Though if so, I'm not sure why the &0xFF bit is needed 
in integer implementation.)  It also returns something that's not 
uniformly distributed in that range, at least on Mac and sometimes on 
Windows (in the sense that there are intervals inside [0, 1) that have 0 
probability of having a number inside that interval returned).


In general, I suspect creating a good definition for the float version 
of this API may be hard.


One other thing that perhaps needs to be defined is seeding.  In 
particular, just because you have a cryptographically strong PRNG 
doesn't mean that you can't always seed it with 0 on pageload or 
something dumb like that.  Should we require that the seed be truly 
random or some such?  Or at least not fixed?  Should web pages be able 
to reseed this generator (at least for the web page in question; 
obviously not for others)?


-Boris