Re: Random numbers

On Wed, May 16, 2012 at 6:11 AM, GALINDO Virginie
<Virginie.GALINDO@gemalto.com> wrote:
> Jarred, Wan-Teh, David
[...]
> 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.

I recommend that we just use window.crypto.getRandomValues.

On Wed, May 16, 2012 at 6:57 AM, Philip Gladstone <pgladsto@cisco.com> wrote:
> The definition:
>
> A cryptographically random value is 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.

I agree that RC4 is a bad example.  (A commonly recommended defense is
to throw away the first n bytes of RC4 stream output.)  In Chromium
(Google Chrome), window.crypto.getRandomValues is implemented using
rand_s() on Windows and /dev/urandom on Unix.

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

Both of these are correct.

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

Both of these are good goals.  I don't think it's necessary to specify the
former (a specific test requirement) in the definition though.  The latter is
a fundamental requirement of a "cryptographically secure" PRNG, which
I suspect is why WHATWG didn't mention it in the definition.

Wan-Teh

Received on Wednesday, 16 May 2012 19:36:57 UTC