Re: Random numbers

On 05/16/2012 04:52 PM, David Dahl wrote:
> I am unsure if we need to cover it here, as the WHATWG spec is covering it and browsers have already implemented it via that spec. I implemented the patch for Gecko, which will land soon, see Mozilla bug 440046 and 673432. In the Gecko version we use PK11_GenerateRandom, the entropy source is NSS.

Hello all,

I just joined, and this is my first email to this group. I work at Opera 
Software, maintaining among others the SSL and crypto libraries. I've 
also got a PhD in cryptography from University of Bergen, Norway.

I agree we should not  spec the implementation of the random generator 
itself in detail. Only the top level API behavior (encoding formats and 
such). All browsers (including Opera) already have strong PRNGs, and  
there's not any need to implement anything new, it's better and less 
error prone if we can continue using what we have.

Since this is about random numbers, it doesn't matter that the  
implementations differ as long as the the random stream has strong 
cryptographic properties.

Cheers,
Håvard
> Cheers,
>
> David
>
> ----- Original Message -----
> From: "Philip Gladstone"<pgladsto@cisco.com>
> To: "GALINDO Virginie"<Virginie.GALINDO@gemalto.com>
> Cc: "Wan-Teh Chang"<wtc@google.com>, "Jarred Nicholls"<jarred@webkit.org>, "David Dahl"<ddahl@mozilla.com>, public-webcrypto@w3.org
> Sent: Wednesday, May 16, 2012 8:57:15 AM
> Subject: Re: Random numbers
>
> The definition:
>
>> Acryptographically random valueis a value generated from a
>> cryptographically strong pseudo-random number generator seeded with
>> truly random values. In practice, implementations should generate
>> cryptographically random values using well-established cryptographic
>> pseudo-random number generators, such as RC4, seeded with high-quality
>> entropy, such as from an operating-system entropy source
>> (e.g.,|/dev/urandom|). This document provides no lower-bound on the
>> information theoretic entropy present in cryptographically random
>> values, but implementations should make a best effort to provide as
>> much entropy as practicable.
> is a bit suspect. For example, it specifies RC4 as a possible algorithm
> to use. Unfortunately, RC4 is a very bad choice as the RC4 stream output
> can be distinguished from a random stream. It specifies that the initial
> seed should be truly random. That may be a bit hard to do on some
> platforms. Also, the definition above seems to exclude using real random
> sources to generate the random values (rather than the initial seed). In
> particular, I would want any implementation that provided random numbers
> to be able to pass NIST SP 800-22rev1a test suite. Also, given the
> multi-user nature of the browser, getting new random numbers should not
> reveal anything about prior random numbers.
>
> If someone claims that we don't need cryptographically secure random
> numbers at the JS layer, then I can certainly implement such a generator
> by using the underlying crypto primitives that will be provided. For
> example, DH generates random values (hopefully from a good source) and
> this can be used to seed a pure JS implementation of a random number
> generator. HOWEVER, I would not advocate this approach as it might well
> be difficult to achieve the goals of forwards and backwards
> unpredictability if the workings were exposed at the JS layer. Putting
> this inside the API makes sense as it will eliminate web developers from
> building their own RNGs.
>
> Philip
>
>
>
> On 5/16/2012 9:11 AM, GALINDO Virginie wrote:
>> Jarred, Wan-Teh, David
>>
>> I have been under the Crypto work managed in the WHATWG, which redirects to W3C repositories, and found the same usual suspects behind this feature (e.g. our kind editors ;-). So I have a question about the way we would like the group to manage this random generation - if demonstrated that it is needed by the usecases.
>>
>> Could you please clarify the status of this proposal and recommend the next steps (e.g. remove this item from the HTML domain, or state that it is now endorsed elsewhere in the Web Crypto API, ...). I would like to make sure we do not have multiplication of API across W3C.
>>
>> Regards,
>> Virginie
>>
>>
>> -----Original Message-----
>> From: Wan-Teh Chang [mailto:wtc@google.com]
>> Sent: Tuesday, May 15, 2012 8:31 PM
>> To: Jarred Nicholls
>> Cc: Philip Gladstone; public-webcrypto@w3.org
>> Subject: Re: Random numbers
>>
>> On Tue, May 15, 2012 at 9:28 AM, Jarred Nicholls<jarred@webkit.org>   wrote:
>>> Note that this almost directly correlates with the future decision of
>>> the level of API this WG is aiming to build (low, medium, high) and
>>> the use cases it aims to satisfy, i.e., if crypto RNG is a necessity
>>> for an accepted use case.  Perhaps the next step is to weigh in on or
>>> create use cases that provide more points towards deciding on the API level.
>> Crypto RNG is an important part of a crypto API.  I think this need is already satisfied by window.crypto.getRandomValues.
>>
>> Wan-Teh
>>
>>

Received on Saturday, 19 May 2012 05:41:09 UTC