On Fri, Dec 27, 2019 at 05:08:57PM -0500, Theodore Y. Ts'o wrote: > On Fri, Dec 27, 2019 at 10:22:23PM +0100, Stephan Mueller wrote: > > > So let's take a step back and ask the question: "Exactly what _value_ > > > do you want to provide by creating some kind of true random > > > interface?" What does this enable? What applications does this > > > really help? > > > > There are simply cryptographers who have use cases for such random numbers. > > The core use case is to seed other DRNGs and avoiding the chaining of free- > > running DRNGs. > > For this very specialized use case, what I think the kernel should > provide is maximal transparency; that is, given the DRBG direct access > to the TPM's random number generator, or direct access to the > ChaosKey, and the userspace DRBG should be able to get a list of the > various hardware RNG's, and select one, with the characterization > being done userspace, not in the kernel. One thing the NIST DRBGs have is prediction resistance, which is done by reseeding. If you chain DRBGs, you tell your parent DRBG that you want prediction resistance, so your parent will also reseed. There currently is no way to tell the kernel to reseed. This reseed option might be something that some people would like to see. If such an option is added, I expect that the kernel might block until it has gotten enough new entropy from it's entropy sources. But I don't actually see a need to add such an option. If the kernel provides a good RNG, the only reason I can see why you would like to have direct access to a hwrng is to verify that it's working correctly. That might mean that you put it in some special mode where it returns raw unprocessed values. If the device is in such a mode, it's output will not provide the same entropy per bit, and so I would expect the kernel to stop using it directly. I guess there might be people who would like to use it directly, but I think we should instead encourage them kernel RNG. > You can talk about providing tools that try to make these estimations > --- but these sorts of things would have to be done on each user's > hardware, and for most distro users, it's just not practical. I would check my own hardware if such an option was available. I think it can be useful to see if the current estimates in the kernel are conservative enough or not. But it would require that you can know what the entropy source is, like the keyboard or harddisk. > So if it's just for cryptographers, then let it all be done in > userspace, and let's not make it easy for GPG, OpenSSL, etc., to all > say, "We want TrueRandom(tm); we won't settle for less". I don't think we want that. As far as I know, the only reason for using /dev/random is that /dev/urandom returns data before it has sufficient entropy. Kurt
