linux-kernel - Re: [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:	Wed, 09 Oct 2013 09:24:00 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Theodore Ts'o" <tytso@....edu>,
	Stanimir Varbanov <svarbanov@...sol.com>,
	Rob Herring <rob.herring@...xeda.com>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Matt Mackall <mpm@...enic.com>,
	Herbert Xu <herbert@...dor.hengli.com.au>,
	linux-kernel@...r.kernel.org, Rob Landley <rob@...dley.net>,
	devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 0/2] Add support for Qualcomm's PRNG

On 10/09/2013 09:03 AM, Theodore Ts'o wrote:
> On Wed, Oct 09, 2013 at 08:07:35AM -0700, H. Peter Anvin wrote:
>> There needs to be an architecturally guaranteed lower bound on the
>> entropic content for this to be at all useful.  However, the hwrandom
>> interface is currently expecting fully entropic output (which is almost
>> certainly bogus... consider the PowerPC random number generator[1]) and
>> so using it for a PRNG output is directly wrong.  
> 
> You can specify as a command-line argument (-H) to rngd the entropy
> per bit of input data.  So if you think an entropy source isn't great,
> but has some uncertainty, you could do pass to rngd "-H 0.5" or maybe
> even "-H 0.1".
> 
> Maybe it would be nice to have /dev/hwrandom export the quality of its
> output, but the reality is that most hardware devices don't document
> or export via some programmatic interface how well or how poorly their
> hwrng really might be.  And even if they did, most people, who don't
> have access to scanning electronic microscopes and nanometer probes,
> and the ability to decrypt, reverse engineer, and decompile firmware,
> couldn't know for sure whether or not to believe the claims of the
> hardware or the hardware manufacturer anyway.
> 

There is no -H option in upstream rngd.  It might be in the Debian fork,
but the Debian fork has serious other problems.  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 (they are

/dev/hwrng should definitely export it rather than having to have the
*user* enter that data... the user has even less opportunity than the
vendor and driver maintainer to get this even remotely right, I fear.

It is really problematic when there isn't even anything to hang things
off, and perhaps a real question is if we even should have drivers for
devices where there isn't any kind of documentation given, or if we
should derate them substantially.

The RDRAND code in rngd already has cryptographic (AES) data reduction
and we might want to extend that code to be able to derate other data
sources.

Or we should just move this into a kernel thread and let the pool do that...

	-hpa

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