linux-kernel - Re: rngd

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 15:48:24 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Clemens Ladisch <clemens@...isch.de>, linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: rngd

On Thu, Oct 10, 2013 at 08:08:41AM -0700, H. Peter Anvin wrote:
> 
> Mainly the maintainer isn't merging in fixes from upstream, apparently
> because he has misunderstood their function.

>From the README file from the Debian fork:

rng-tools unofficial-mt is a living reminder to myself to not modify upstream
code without sending the changes upstream at every step.  Suddenly, you have a
mass of changes too big to send upstream, and yet you find yourself without the
energy to break them into smallish patches to submit upstream (i.e. to
"unfork").

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

... and to the extent that output is crypto-whitened in the hardware,
with no way of disabling the whitening, it's actually kind of hopeless
to do any kind of testing.

One of the reasons why I wanted to keep this functionality in
userspace, as opposed to moving this into a kernel thread, is because
I was hoping someone would create hardware which did not do hardware
whitening, and userspace could do proper quality checking of the
entropy source, and data reduction as necessary, all in the an open
and auditable way.  If we are doing the those more heavyweight tests,
it's not a clear it makes sense to put all of this in the kernel.

     	   	    	  	       - Ted
--
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/