RE: Proposal: getRandomValues for Workers

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