Searched hist:"48 d6be955a7167b0d0e025ae6c39e795e3544499" (Results 1 – 1 of 1) sorted by relevance
| /linux/drivers/char/ |
| H A D | random.c | diff 48d6be955a7167b0d0e025ae6c39e795e3544499 Thu Jul 17 11:27:30 CEST 2014 Theodore Ts'o <tytso@mit.edu> random: limit the contribution of the hw rng to at most half
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>
|