Re: [PATCH 0/2] Add support for Qualcomm's PRNG

["H. Peter Anvin" <hpa@zytor.com>]

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