linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Clemens Ladisch <clemens@ladisch.de>,
	"Theodore Ts'o" <tytso@mit.edu>,
	linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: rngd
Date: Thu, 10 Oct 2013 08:08:41 -0700	[thread overview]
Message-ID: <5256C2F9.8090707@zytor.com> (raw)
In-Reply-To: <52565B56.1070606@ladisch.de>

On 10/10/2013 12:46 AM, Clemens Ladisch wrote:
> 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?
> 

Mainly the maintainer isn't merging in fixes from upstream, apparently
because he has misunderstood their function.

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

Yes.  I don't think the FIPS tests make any sense at all (up to and
including rngd 3 they would eventually kill rngd, because it only
allowed for a fixed number of false positives.)

	-hpa



  reply	other threads:[~2013-10-10 15:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-03 14:52 [PATCH 0/2] Add support for Qualcomm's PRNG Stanimir Varbanov
2013-10-03 14:52 ` [PATCH 1/2] ARM: DT: msm: Add Qualcomm's PRNG driver binding document Stanimir Varbanov
2013-10-03 14:52 ` [PATCH 2/2] hwrng: msm: Add PRNG support for MSM SoC's Stanimir Varbanov
2013-10-03 19:25   ` Stephen Boyd
2013-10-04 16:31     ` Stanimir Varbanov
2013-10-04 16:37       ` Stephen Boyd
2013-10-09  8:23         ` Stanimir Varbanov
2013-10-03 16:51 ` [PATCH 0/2] Add support for Qualcomm's PRNG Theodore Ts'o
2013-10-04 16:23   ` Stanimir Varbanov
2013-10-04 18:10     ` Theodore Ts'o
2013-10-09 14:46       ` Stanimir Varbanov
2013-10-09 15:07         ` H. Peter Anvin
2013-10-09 16:03           ` Theodore Ts'o
2013-10-09 16:24             ` H. Peter Anvin
2013-10-10  7:46               ` rngd (was: [PATCH 0/2] Add support for Qualcomm's PRNG) Clemens Ladisch
2013-10-10 15:08                 ` H. Peter Anvin [this message]
2013-10-10 19:48                   ` rngd Theodore Ts'o
2013-10-10 10:41           ` [PATCH 0/2] Add support for Qualcomm's PRNG Paul Mackerras
2013-10-10 15:08             ` H. Peter Anvin
2013-10-10 13:47           ` Stanimir Varbanov
2013-10-11  7:05             ` Clemens Ladisch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5256C2F9.8090707@zytor.com \
    --to=hpa@zytor.com \
    --cc=clemens@ladisch.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).