On Tue, 21 May 2013 12:09:02 -0400 Sandy Harris <sandyinchina@xxxxxxxxx> wrote: Hi Sandy, > I very much like the basic notion here. The existing random(4) driver > may not get enough entropy in a VM or on a device like a Linux router > and I think work such as yours or HAVEGE ( > http://www.irisa.fr/caps/projects/hipsor/) are important research. The > paper by McGuire et al of "Analysis of inherent randomness of the > Linux > kernel" (http://lwn.net/images/conf/rtlws11/random-hardware.pdf) > seems to show that this is a fine source of more entropy. > > On the other hand, I am not certain you are doing it in the right > place. My own attempt (ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/) > put it in a demon that just feeds /dev/random, probably also not the > right place. haveged(8) ( http://www.issihosts.com/haveged/) also > puts it in a demon process. It may, as you suggest, belong in the > kernel instead, but I think there are arguments both ways. Thanks for your insights. What I propose is that it shall NOT have any fixed place at all. The entropy collection shall be as close to the "consumer" as possible. There shall be NO single one entropy collector, but one for every consumer. That is the reason, why the code I am offering has that many links to different crypto libs or even a stand-alone shared lib compilation. Also, the implementation for the kernel crypto API should be used in a way where one "consumer" instantiates the raw RNG or even the DRNGs independently from others. That means, in-kernel users of entropy like IPSEC shall instantiate the the kernel crypto API code independently of others. > > Could we keep random(4) mostly as is and rearrange your code to just > give it more entropy? I think the large entropy pool in the existing > driver is essential since we sometimes want to generate things like a > 2 Kbit PGP key and it is not clear to me that your driver is entirely > trustworthy under such stress. We can easily do that -- the different links I provide to different crypto libs can be extended by a patch to random(4) too. My goal is to go away from a central source of entropy to a fully decentralized source. Ciao Stephan -- | Cui bono? | -- 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
