Re: Random numbers

On May 16, 2012, at 11:35 AM, Håvard Molland wrote:

> 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.

Agreed, the API should describe the properties provided by the random source (i.e. the requirements on the provider of randomness) but should not specify a particular method.

One important property for webcrypto is "backtracking resistance", in the terminology of SP800-90; that is, the property that an adversary that knows some outputs of the random source does not have any advantage at guessing any other outputs from that source.    The main requirement should probably be that the min-entropy in any n-bit output is at least n-1, or something like that.  

David

> 
> 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 Tuesday, 22 May 2012 12:46:21 UTC