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

-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ