- From: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
- Date: Fri, 12 Oct 2012 21:55:18 +0200
- To: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- CC: Ryan Sleevi <sleevi@google.com>, Nadim Kobeissi <nadim@nadim.cc>
Dear all, Anymore comment on this proposal from Ryan ? Regards, Virginie -----Original Message----- From: Nadim Kobeissi [mailto:nadim@nadim.cc] Sent: jeudi 11 octobre 2012 02:48 To: Ryan Sleevi Cc: public-webcrypto@w3.org Subject: Re: Proposal: getRandomValues for Workers Sending part of thread which dropped from the WG list by mistake: On 10/10/2012 8:44 PM, Ryan Sleevi wrote: > On Wed, Oct 10, 2012 at 5:34 PM, Nadim Kobeissi <nadim@nadim.cc> wrote: >> Ah, I meant that we might want to exploit the benefit of having >> getRandomValues in workers in order to make it possible to use >> blocking sources of randomness, since /dev/random produces much more >> reliably random data than say, /dev/urandom. It could be a useful >> feature to add for operations that can't compromise on the quality of random seeds. >> Since workers can run in the background forever, this sort of thing >> becomes possible. >> >> NK > > Did you mean to drop the WG? If so, please feel free to reply with them copied. > > Sure. I just don't see it likely at all for user agents to do - it's > blocking because it drains entropy, and you don't want arbitrary web > apps to drain all the entropy (and thus act as a denial of service to > apps that really do care about crypto). That's a gaping security hole > waiting to happen. > > The need for "more reliable sources of entropy" only come up (I > believe) when trying to implement your own RNG, which is the explicit > non-goal. This goal is to provide the high quality ("strong enough") > RNG. > >> >> On 10/10/2012 8:31 PM, Ryan Sleevi wrote: >>> No, it does not make it any easier or harder to do so. >>> >>> Implementations can already do that today - getRandomValues is >>> declared as blocking - it's just an undesirable characteristic. >>> Despite the fact that "blocking" APIs are permitted on workers, the >>> availability of such APIs does not make it any better or desirable >>> to actually implement said APIs using blocking methods (blocking >>> file reads via FileAPI or via /dev/random). >>> >>> Also, I suspect (but have not fully considered) that exposing such >>> blocking sources of randomness may be highly undesirable to expose >>> to web content (entropy drain). The previous specification (from >>> WHATWG) specifically stated that it was a value obtained from a >>> *generator* seeded with truly random values/high quality values. >>> >>> On Wed, Oct 10, 2012 at 5:20 PM, Nadim Kobeissi <nadim@nadim.cc> wrote: >>>> This would totally pave the way for being able to use blocking >>>> sources of randomness as well, like /dev/random >>>> >>>> NK >>>> >>>> On 10/10/2012 8:13 PM, Ryan Sleevi wrote: >>>>> The current Editor's Draft, as well as the FPWD, do not currently >>>>> specify which objects implement the "Crypto" interface. As >>>>> previously discussed, the intent was that there would be normative >>>>> text to the effect of >>>>> >>>>> partial interface Window { >>>>> readonly attribute Crypto crypto }; >>>>> >>>>> which enables window.crypto.* to actually work. This was >>>>> previously included in the WHATWG work - >>>>> http://wiki.whatwg.org/index.php?title=Crypto&oldid=8471 >>>>> >>>>> While we still need to resolve issues regarding the synchronous >>>>> API ( ISSUE 24 ), I'd like to propose that crypto.getRandomValues >>>>> be exposed via WorkerGlobalScope >>>>> >>>>> partial interface WorkerCrypto { >>>>> ArrayBufferView getRandomValues(ArrayBufferView array); }; >>>>> >>>>> partial interface WorkerGlobalScope { >>>>> readonly attribute WorkerCrypto crypto; }; >>>>> >>>>> >>>>> Note that I'm not (yet) proposing exposing the entire Crypto interface >>>>> - I think there's a lot of unspecified behaviour regarding multiple >>>>> 'threads' (let alone browsing contexts) performing operations with >>>>> Keys that will need to be carefully thought through, but it seems >>>>> reasonable to propose that this specific method be made available to >>>>> workers as well. >>>>> >>>>> Mozilla has currently implemented window.crypto.getRandomValues ( >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=440046 ), and it has also >>>>> been implemented in WebKit (as used by Safari and Chromium/Chrome - >>>>> https://bugs.webkit.org/show_bug.cgi?id=22049 ) >>>>> >>>>> It's not clear to me whether it's necessary to specify a WorkerCrypto >>>>> object, but since I imagine that there will be methods (or >>>>> constructors) that are specific to Workers (since synchronous APIs on >>>>> the global Window object are wholly undesirable), it seems like the >>>>> good first start. >>>>> >>>>
Received on Friday, 12 October 2012 19:55:44 UTC