RE: [PATCH 2/2] ath9k: disable RNG by default

Hi Stephan,

FIPS RNG test is supposed to be run on the output of an RNG, and not on the RNG entropy source. It is not surprising that the RNG input fails the entropy tests from NIST. Check the following example.

Imagine you have a perfectly random sequence, a_1, a_2, .., a_n, where each a_i is a byte. And imagine, this sequence passes all randomness tests.

Now, let's say I create a new sequence a_1, 0, a_2, 0, a_3, 0, ..., 0, a_n, where each zero is a byte

If you give this sequence (as an entropy source) to a randomness test, it will fail most of the tests, if not all. This does not mean this sequence is not appropriate as an entropy source, it just means we need twice more bytes to gain the same amount of entropy.

I can give this 2n byte sequence to an RNG as an entropy source and it provides the same amount of security as if I give the n byte stream.

Thanks,
Miaoqing

-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de] 
Sent: Wednesday, August 10, 2016 1:29 PM
To: Pan, Miaoqing <redacted>
Cc: Herbert Xu <herbert@gondor.apana.org.au>; Matt Mackall <redacted>; miaoqing@codeaurora.org; Valo, Kalle <redacted>; linux-wireless@vger.kernel.org; ath9k-devel <redacted>; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan <redacted>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default

Am Mittwoch, 10. August 2016, 02:35:04 CEST schrieb Pan, Miaoqing:

Hi Miaoqing,

Hi Stephan,

For those less perfect noise source, can't pass the FIPS test.

static int update_kernel_random(int random_step,
        unsigned char *buf, fips_ctx_t *fipsctx_in) {
        unsigned char *p;
        int fips;

        fips = fips_run_rng_test(fipsctx_in, buf);
        if (fips)
                return 1;

        for (p = buf; p + random_step <= &buf[FIPS_RNG_BUFFER_SIZE];
                 p += random_step) {
                random_add_entropy(p, random_step);
                random_sleep();
        }
        return 0;
}

Not even the poor cheap AIS20 statistical tests from rngd pass?

I guess the only sensible solution is what Ted suggested to use add_device_randomness.

Ciao
Stephan

Am Mittwoch, 10. August 2016, 06:04:32 CEST schrieb Pan, Miaoqing:

Hi Miaoqing,

Hi Stephan,

FIPS RNG test is supposed to be run on the output of an RNG, and not on the
RNG entropy source. It is not surprising that the RNG input fails the
entropy tests from NIST. Check the following example.

Imagine you have a perfectly random sequence, a_1, a_2, .., a_n, where each
a_i is a byte. And imagine, this sequence passes all randomness tests.

Now, let's say I create a new sequence a_1, 0, a_2, 0, a_3, 0, ..., 0, a_n,
where each zero is a byte

If you give this sequence (as an entropy source) to a randomness test, it
will fail most of the tests, if not all. This does not mean this sequence
is not appropriate as an entropy source, it just means we need twice more
bytes to gain the same amount of entropy.

Agreed. But that is a very simplistic view.

I can give this 2n byte sequence to an RNG as an entropy source and it
provides the same amount of security as if I give the n byte stream.

Well, I am working with standards bodies like NIST and BSI on RNG 
assessments. They all require that the noise source (pre-whitening, of 
course) pass statistical tests like the AIS20 tests, SP800-22 and similar. If 
you fail, you better have a good argument.

And the only argument that is kind of allowed is that you oversample your 
noise source to seed a DRNG from (i.e. have an entropy to data ratio of 
significantly below 1). And the argument for the oversampling rate is always 
a very interesting discussion. You apply 10/32. In private, I am wondering 
about that ratio, but this should not be discussed here as I hope you have a 
valid argument for that.

As we are talking about the current rngd, we have to consider that it does 
*not* perform an oversampling (yet) as mentioned in the previous emails.

Do not get me wrong on my initial patch: your RNG may provide some entropy. 
But there are quite some folks who want to understand and audit a noise 
source before using it. Your current implementation simply does not allow 
switching the noise source off to feed the input_pool with data that 
increases the entropy estimator (at runtime).

Ciao
Stephan