[whatwg] Cryptographically strong random numbers
shabsi at google.com
Mon Feb 14 12:20:02 PST 2011
Re-posting for es-discuss
On Mon, Feb 14, 2011 at 8:30 AM, Shabsi Walfish <shabsi at 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, everything else is already
> the existing implementations, as Adam points out.
> On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth <w3c at adambarth.com> wrote:
>> On Sun, Feb 13, 2011 at 10:12 PM, Mark S. Miller <erights at google.com>
>> > On Sun, Feb 13, 2011 at 6:37 PM, Boris Zbarsky <bzbarsky at mit.edu>
>> >> 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
>> >> 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
>> >> API like this (something that fills in an array of bytes with
>> >> cryptographically strong random values) in any sort of short-term
>> > Thanks for checking. The answer is yes. I'm scheduled to start a
>> > of <http://wiki.ecmascript.org/doku.php?id=strawman:random-er> at
>> either the
>> > upcoming March or May meetings. Currently random-er is on the agenda for
>> > 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
>> > and Bill Frantz, all cc'ed, about the possibility of a real crypto API
>> > EcmaScript. With the sole exception of randomness, I believe that we
>> > handle this the same way we're handling i18n -- as a separate working
>> > within tc39 (the EcmaScript committee) working on a separate standard
>> > library in a separate standards document. The reason to make an
>> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss