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
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,
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
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),
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 bren...@mozilla.org wrote:
On Feb 22, 2011, at 2:49 PM, Erik Corry wrote:
I can find Klein's complaints that the implementation of
On Tue, Feb 22, 2011 at 6:26 PM, Bill Frantz fra...@pwpconsult.com 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
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
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
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
On Wed, Feb 16, 2011 at 11:36 AM, Oliver Hunt oli...@apple.com 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,
On Mon, Feb 14, 2011 at 8:03 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
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
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
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
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,
On Wed, Feb 16, 2011 at 4:29 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
So, let's get back to the design of an actual ECMAScript API.
I'll repeat a couple of initial points:
We are now talking about a pure JavaScript API,
Good stuff.
Recall that part of what started this is
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
On Thu, Feb 17, 2011 at 08:29, Allen Wirfs-Brock al...@wirfs-brock.com 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
On Sun, Feb 13, 2011 at 10:12 PM, Mark S. Miller erig...@google.com wrote:
On Sun, Feb 13, 2011 at 6:37 PM, Boris Zbarsky bzbar...@mit.edu 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
On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth 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.
The committee meets once every two months. Between meetings, we
On 2/14/11 11:31 AM, Mark S. Miller wrote:
On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth w...@adambarth.com
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
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 w...@adambarth.com
mailto:w...@adambarth.com wrote:
That's a pretty long time horizon. You're going to start discussing
it in 2-4 months? That
On Mon, Feb 14, 2011 at 8:31 AM, Mark S. Miller erig...@google.com wrote:
On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth 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
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
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
On Mon, Feb 14, 2011 at 11:56 AM, Brendan Eich bren...@mozilla.org 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
On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:
On Mon, Feb 14, 2011 at 11:56 AM, Brendan Eich bren...@mozilla.org 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
On Fri, Feb 11, 2011 at 1:36 PM, Adam Barth w...@adambarth.com 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
On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich bren...@mozilla.org wrote:
On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:
On Mon, Feb 14, 2011 at 11:56 AM, Brendan Eich bren...@mozilla.orgwrote:
On Feb 14, 2011, at 11:31 AM, Adam Barth wrote:
What's non-interoperable about filling an
On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich bren...@mozilla.org 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
On Mon, Feb 14, 2011 at 5:08 PM, Adam Barth w...@adambarth.com wrote:
On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich bren...@mozilla.org
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
[Hopefully my subscription change to es-discuss has gone through by now.]
On Mon, Feb 14, 2011 at 2:25 PM, Mark S. Miller erig...@google.com 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
On Mon, Feb 14, 2011 at 5:46 PM, Shabsi Walfish sha...@google.com 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
On Feb 14, 2011, at 1:29 PM, Adam Barth wrote:
On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich bren...@mozilla.org wrote:
On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:
On Mon, Feb 14, 2011 at 11:56 AM, Brendan Eich bren...@mozilla.org wrote:
On Feb 14, 2011, at 11:31 AM, Adam Barth wrote:
On Mon, Feb 14, 2011 at 6:43 PM, Shabsi Walfish sha...@google.com 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
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
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
On Sun, Feb 13, 2011 at 11:35 AM, David Bruant
bru...@enseirb-matmeca.fr 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
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.
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
[+benl, +shabsi, +frantz, +daw]
On Sun, Feb 13, 2011 at 6:37 PM, Boris Zbarsky bzbar...@mit.edu 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
On Fri, Feb 11, 2011 at 5:08 PM, Cedric Vivier cedr...@neonux.com wrote:
On Sat, Feb 12, 2011 at 04:40, Adam Barth w...@adambarth.com wrote:
Is there a specific reason for this limitation?
Imho it should throw only for Float32Array and Float64Array since
unbounded random floating numbers does
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
On Fri, Feb 11, 2011 at 6:38 AM, Adam Barth w...@adambarth.com 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 {
On Fri, Feb 11, 2011 at 19:38, Adam Barth w...@adambarth.com 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
On Fri, Feb 11, 2011 at 4:32 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Feb 11, 2011 at 6:38 AM, Adam Barth w...@adambarth.com 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
On Fri, Feb 11, 2011 at 3:40 PM, Adam Barth w...@adambarth.com 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
On Fri, Feb 11, 2011 at 1:13 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Feb 11, 2011 at 3:40 PM, Adam Barth w...@adambarth.com 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
On Sat, Feb 12, 2011 at 04:40, Adam Barth w...@adambarth.com 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
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
On Sat, 05 Feb 2011 17:18:05 +0100, Boris Zbarsky bzbar...@mit.edu 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
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
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
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
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.
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
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
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
On 2011-02-05 11:10, Adam Barth wrote:
On Fri, Feb 4, 2011 at 9:00 PM, Cedric Viviercedr...@neonux.com 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
On Sun, Feb 6, 2011 at 11:34, Roger Hågensen resca...@emsai.net 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.
On Sat, Feb 5, 2011 at 11:07 PM, Cedric Vivier cedr...@neonux.com 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
On 2011-02-06 05:07, Cedric Vivier wrote:
On Sun, Feb 6, 2011 at 11:34, Roger Hågensenresca...@emsai.net 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
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
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
On Fri, Feb 4, 2011 at 7:39 PM, Boris Zbarsky bzbar...@mit.edu 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
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
On Fri, Feb 4, 2011 at 8:01 PM, Boris Zbarsky bzbar...@mit.edu 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
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
On Fri, Feb 4, 2011 at 8:18 PM, Boris Zbarsky bzbar...@mit.edu 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
Hi,
On Sat, Feb 5, 2011 at 08:42, Adam Barth w...@adambarth.com 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 {
On Fri, Feb 4, 2011 at 9:00 PM, Cedric Vivier cedr...@neonux.com wrote:
Hi,
On Sat, Feb 5, 2011 at 08:42, Adam Barth w...@adambarth.com wrote:
interface Crypto {
Float32Array getRandomFloat32Array(in long length);
Uint8Array getRandomUint8Array(in long length);
};
I think the API would
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
71 matches
Mail list logo
