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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Oct 2013 09:46:30 +0200
From:	Clemens Ladisch <clemens@...isch.de>
To:	"H. Peter Anvin" <hpa@...or.com>, Theodore Ts'o <tytso@....edu>,
	linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: rngd (was: [PATCH 0/2] Add support for Qualcomm's PRNG)

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/