Re: [PATCH] random: limit the contribution of the hw rng to at most half

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

On 07/17/2014 03:03 AM, Theodore Ts'o wrote:
> For people who don't trust a hardware RNG which can not be audited,
> the changes to add support for RDSEED can be troubling since 97% or
> more of the entropy will be contributed from the in-CPU hardware RNG.
> 
> We now have a in-kernel khwrngd, so for those people who do want to
> implicitly trust the CPU-based system, we could create an arch-rng
> hw_random driver, and allow khwrng refill the entropy pool.  This
> allows system administrator whether or not they trust the CPU (I
> assume the NSA will trust RDRAND/RDSEED implicitly :-), and if so,
> what level of entropy derating they want to use.
> 
> The reason why this is a really good idea is that if different people
> use different levels of entropy derating, it will make it much more
> difficult to design a backdoor'ed hwrng that can be generally
> exploited in terms of the output of /dev/random when different attack
> targets are using differing levels of entropy derating.
> 
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>

I saw exactly one complaint to that nature, but that was from someone
who really wanted the "nordrand" option (at which point I observed that
it had inadvertently left RDSEED enabled which quickly got rectified.)
The implication was that this was a request from a specific customer who
presumably have their own "audited" hardware RNG.

There may have been other complaints (justified or not) but if so I
haven't seen them.  I'm wondering if we are overgeneralizing here and if
so if it wouldn't be better to defer this until the hwrng supplier for
this is ready, which probably won't happen in time for 3.17 just given
the current timeline.

	-hpa