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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
