Having got up to speed on this discussion after a holiday here are my
thoughts from a V8er:
* I would prefer to see this in the DOM rather than in the language.
Can't see why it needs to be in the language itself. Other languages
generally don't have cryptographically secure random numbers in
On Feb 22, 2011, at 5:31 AM, Erik Corry wrote:
Having got up to speed on this discussion after a holiday here are my
thoughts from a V8er:
* I would prefer to see this in the DOM rather than in the language.
Can't see why it needs to be in the language itself. Other languages
generally
I'm from the better to ask forgiveness than permission school, so I'm rooting
for Adam's work to catch on among browsers and ultimately reach w3c
standardization.
Even the typed array usage is ok if we harmonize the tiny subset of typed
arrays used there (no aliasing!) with
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 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
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),
I didn't see a way to set the seed of Math.random(), so the
ECMAScript/Javascript version lacks this useful property.
Butting in, for a moment... I thought JavaScript seeded the PRNG with the
timestamp by default? Perhaps I'm totally off base, but that's long been my
assumption, and the
On Feb 22, 2011, at 3: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
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 2/22/11 at 3:39 PM, bren...@mozilla.com (Brendan Eich) wrote:
The API issue as Erik put it is this: do we need an array of
bytes/shorts/ints, potentially a lot of random values; or would
the fractional bits of a single IEEE 64-bit double precision
result be good enough.
When doing
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
Brendan Eich wrote:
I'm happy if the answer is all OSes, mobile and desktop, provide enough
high quality randomness. Looking for data if anyone has it.
Here's what I've been able to find.
All desktop OSes that I'm aware of provide a way to get
crypto-quality randomness, including Windows, Mac,
On Feb 16, 2011, at 12:45 PM, David Wagner wrote:
Brendan Eich wrote:
I'm happy if the answer is all OSes, mobile and desktop, provide enough
high quality randomness. Looking for data if anyone has it.
Here's what I've been able to find.
All desktop OSes that I'm aware of provide a way
[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
Shabsi Walfish writes:
I think the question is whether or not this can be done in general without
blocking -- if you block, you can definitely get crypto-quality random
numbers, but otherwise its not clear... Personally, I think it makes sense
for the browser to have its own PRNG, and to get
Thanks, this matches what I heard from mobile folks we are working with.
/be
On Feb 16, 2011, at 9:45 AM, David Wagner wrote:
Brendan Eich wrote:
I'm happy if the answer is all OSes, mobile and desktop, provide enough
high quality randomness. Looking for data if anyone has it.
Here's what
On Wed, Feb 16, 2011 at 11:13 AM, David Wagner d...@cs.berkeley.edu wrote:
Shabsi Walfish wrote (quoting from the urandom(4) man page):
A read from the */dev/urandom* device will not block waiting for more
entropy. As a result, if there is not sufficient entropy in the entropy
pool, the
On Wed, Feb 16, 2011 at 11:31 AM, Mark S. Miller erig...@google.com wrote:
On Wed, Feb 16, 2011 at 11:13 AM, David Wagner d...@cs.berkeley.eduwrote:
Shabsi Walfish wrote (quoting from the urandom(4) man page):
A read from the */dev/urandom* device will not block waiting for more
entropy.
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 Feb 16, 2011, at 11:31 AM, Mark S. Miller wrote:
This issue seems to be the only significant remaining controversy here, so
more words settling it more decisively would be welcome. Thanks.
Not to drag this out, but the randomness quality issue (or non-issue, now) is
not the only
On Wed, Feb 16, 2011 at 11:05 AM, David Wagner d...@cs.berkeley.edu wrote:
Shabsi Walfish writes:
I think the question is whether or not this can be done in general
without
blocking -- if you block, you can definitely get crypto-quality random
numbers, but otherwise its not clear...
. Miller erig...@google.com
Cc: es-discuss es-discuss@mozilla.org
Sent: Wed, February 16, 2011 12:00:37 PM
Subject: Re: [whatwg] Cryptographically strong random numbers
On Feb 16, 2011, at 11:31 AM, Mark S. Miller wrote:
This issue seems to be the only significant remaining controversy here, so
more
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
Too much and too complex, say I! ;)
I liked your previous thinking that we should just return a fresh array. And in
the interest of keeping it dead simple, let's just fix it at 32 bits -- always.
Then the question is: string, array, typed array, or binary data?
I say: let's make it typed array
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 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
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 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 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
Re-posting for es-discuss
On Mon, Feb 14, 2011 at 8:30 AM, Shabsi Walfish sha...@google.com wrote:
I think a good source of cryptographically secure entropy is _much_ higher
priority than any other crypto related APIs you might consider
standardizing... given a good source of entropy,
Re-posting for es-discuss
On Mon, Feb 14, 2011 at 12:01 PM, Shabsi Walfish sha...@google.com wrote:
On Mon, Feb 14, 2011 at 11:31 AM, Adam Barth w...@adambarth.com wrote:
On Mon, Feb 14, 2011 at 8:31 AM, Mark S. Miller erig...@google.comwrote:
On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth
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 12:01 PM, Shabsi Walfish sha...@google.com wrote:
On Mon, Feb 14, 2011 at 11:31 AM, Adam Barth w...@adambarth.com wrote:
On Mon, Feb 14, 2011 at 8:31 AM, Mark S. Miller erig...@google.comwrote:
On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth w...@adambarth.com wrote:
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
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
[adding Cameron McCormack, Web IDL editor, to the discussion]
Le 14/02/2011 22:29, Adam Barth a écrit :
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
If the intent is to get ECMAScript implementations to quickly provide this
function then I would suggest that it be specified only in terms of things that
are already in ES5. That would preclude use of anything from the Harmony
binary data strawman.
I don't particularly see why a binary array
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
OpenSSL is not exactly a reliable source of cryptographic best practices. :)
In any case, see here http://linux.die.net/man/4/urandom :
When read, the */dev/random* device will only return random bytes within the
estimated number of bits of noise in the entropy pool. */dev/random* should
be
On 2/14/11 at 2:46 PM, sha...@google.com (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
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
On Feb 14, 2011, at 4:47 PM, Brendan Eich wrote:
The IDL's use of an array inout parameter
Er, in parameter, of course -- but with an in ArrayBufferView parameter (a
reference to a mutable object), there's an out channel too, via effects on
the viewed data in the buffer. Which is why I wrote
[wha...@lists.whatwg.org removed from cc list because I'm not on
it and MarkM suggested dropping it.]
On 2/14/11 at 4:20 PM, sha...@google.com (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
On Mon, Feb 14, 2011 at 7:20 PM, Shabsi Walfish sha...@google.com 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
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
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.
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
[+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
57 matches
Mail list logo
