On 03/03/2014 03:51 PM, Kees Cook wrote: > When bringing a new RNG source online, it seems like it would make sense > to use some of its bytes to make the system entropy pool more random, > as done with all sorts of other devices that contain per-device or > per-boot differences. > > Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx> I would like to raise again the concept of at least optionally using a kernel thread, rather than a user-space daemon, to feed hwrng output to the kernel pools. The main service rngd provides is FIPS tests, but those FIPS tests were withdrawn as a standard over 10 years ago and are known to be extremely weak, at the very best a minimal sanity check. Furthermore, they are completely useless against the output of any RNG which contains a cryptographic whitener, which is the vast majority of commercial sources -- this is especially so since rngd doesn't expect to have to do any data reduction for output coming from hwrng. Furthermore, if more than one hwrng device is available, rngd will only be able to read one of them because of the way /dev/hwrng is implemented in the kernel. For contrast, the kernel could do data reduction just fine by only crediting the entropy coming out of each hwrng driver with a fractional amount. That does *not* mean that there aren't random number generators which require significant computation better done in user space. For example, an audio noise daemon or a lava lamp camera which requires video processing. -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
