Re: rngd (was: [PATCH 0/2] Add support for Qualcomm's PRNG)

[Clemens Ladisch <clemens@ladisch.de>]

H. Peter Anvin wrote:
> On 10/09/2013 09:03 AM, Theodore Ts'o wrote:
>> You can specify as a command-line argument (-H) to rngd the entropy
>> per bit of input data.
>
> There is no -H option in upstream rngd.  It might be in the Debian fork,
> but the Debian fork has serious other problems.

What problems?  I have been thinking about adding another entropy source
to rngd, and was wondering which fork to use, or if it would make sense
to merge them.  Are there any features of the Debian fork that should
not be ported to upstream?

> I don't understand how that would work with the FIPS tests in rngd,
> unless of course the FIPS tests are so weak they are pointless anyway

Most of the FIPS tests assume that the bits are independently generated
(the two other tests check for correlations in 4/32-bit groups).  None
of these tests make sense if the bit stream is the output of an AES
conditioner.  For RDRAND, it might be useful to check that we don't
accidentally get a series of zeros or something like that, but otherwise
we have to trust the built-in tests that Intel claims the hardware is
doing before conditioning.

As it happens, the 2002-12-03 change notice of FIPS 140-2 dropped the
RNG tests.


For the entropy source I've been thinking about (captured audio
samples), the FIPS tests would make sense only if done independently on
each bit in the sample (e.g., with 24-bit samples, there would be 24
parallel bit streams, most of which wouldn't be random).  Additional
tests to check for correlations between the bits in a sample would be
useful, too.

What I'm trying to say with all this is that self-tests must be
customized for each entropy source.


Regards,
Clemens