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@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
