> On Aug 29, 2019, at 6:49 PM, Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > >> On Thu, Aug 29, 2019 at 06:11:35PM -0700, Andy Lutomirski wrote: >> This series also removes the blocking pool and makes /dev/random >> work just like getentropy(..., 0) and makes GRND_RANDOM a no-op. I >> believe that Linux's blocking pool has outlived its usefulness. >> Linux's CRNG generates output that is good enough to use even for >> key generation. The blocking pool is not stronger in any material >> way, and keeping it around requires a lot of infrastructure of >> dubious value. > > It's too late for the 5.4 cycle for a change of this magnitude, and > I'd just as soon let this wait until *after* the LTS kernel gets cut. > The reason for this is because at the moment, there are some PCI > compliance labs who believe that the "true randomness" of /dev/random > is necessary for PCI compliance and so they mandate the use of > /dev/random over /dev/urandom's "cryptographic randomness" for that > reason. A lot of things which are thought to be needed for PCI > compliance that are about as useful as eye of newt and toe of frog, > but nothing says that PCI compliance (and enterprise customer > requirements :-) have to make sense. > > It may be that what we might need to really support people (or stupid > compliance labs) who have a fetish for "true randomness" to get a > better interface for hardware random number generators than > /dev/hwrng. Specifically, one which allows for a more sane way of > selecting which hardware random number generator to use if there are > multiple available, and also one where we mix in some CRNG as a > whitening step just case the hardware number generator is busted in > some way. (And to fix the issue that at the moment, if someone evil > fakes up a USB device with the USB manufacturer and minor device > number for a ChosKey device that generates a insecure sequence, it > will still get blindly trusted by the kernel without any kind of > authentication of said hardware device.) > > That probably means we need to come up with a new interface than > /dev/hwrng, or have some way of configuring /dev/random to use a > hardware RNG device for those people who really care about "true > randomness". The current /dev/hwrng interface and how it is > configured via sysfs is pretty baroque IMO. > > Hmm. Does this really need to be in the kernel? ISTM it should be straightforward to write a little CUSE program that grabs bytes from RDSEED or RDRAND, TPM, ChaosKey (if enabled, with a usb slot selected!), and whatever other sources are requested and, configurable to satisfy whoever actually cares, mixes some or all with a FIPS-compliant, provably-indististinguishable-from-random, definitely not Dual-EC mixer, and spits out the result. And filters it and checks all the sources for credibility, and generally does whatever the user actually needs. And the really over-the-top auditors can symlink it to /dev/random. Do the PCI folks actually care that it’s in the kernel? As an aside, the first two patches could plausibly land before the rest of the series if that seems appropriate.
