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 Thursday, 11 October 2012 00:48:04 UTC