On Tue, Feb 25, 2020 at 09:27:07AM -0700, stan wrote: > On Tue, 25 Feb 2020 08:17:37 -0500 > Neil Horman <nhorman@xxxxxxxxxx> wrote: > > > Just out of curiosity, instead of patching the kernel to feed entropy > > from your SDN directly into the kernel, have you considered just > > adding this as an entropy source to rngd? That would save you the > > trouble of having to patch the kernel to do this. I'd be interested > > in getting a feature like that into place for rngd > > I didn't. Even though I used rngtest while validating the output. > Hmmm. These changes to random.c mean that rngd is also going to stop > working to feed entropy as well, since /dev/random can no longer be used > to feed entropy into the pool (that's how I understand the changes, at > least). > Thats not my understanding. As I understand the changes, /dev/random has been converted so that its no longer blocks (which is why the removed the read_wakeup_threshold, since theres never a case where /dev/random will block anymore). That doesn't prevent rngd from feeding new entropy into the kernel though, via /dev/randoms RNDADDTOENTCNT and RNDADDENTROPY ioctls (which is how we feed in more entropy) > That said, I have no issues with integration into rngd. The code is > released gplv3 on sourceforge, but I can relicense it as gplv2 for you > if needed. It hasn't changed since I developed it, only the way of > getting it into the kernel and using it there has needed to be updated. I'm fine with gplv3, IIRC rngd was initially licensed as gplv2 or later, so it should be good. > A few iterations ago, random.c removed the ability to reseed the crng > on a timed basis, instead checking whether there was enough entropy for > a reseed and a cool down period had passed each time a call was made to > get random bytes. I also re-introduced periodic reseeds; entropy to > burn, why not use it. I checked the output last year, and it was still > passing all the tests. I used the NSA tests this time, as well as > rngtest and dieharder, and they also passed. Of course, passing tests > isn't a guarantee, but it does give a level of confidence. > > I modelled the daemon on the existing audio-entropyd, which I also use. > It isn't very efficient, but a paper I read a few years ago found that > multiple sources of uncorrelated entropy, even 'bad' entropy, meaning > there might be only 2 or 3 bits of entropy per byte, made crngs more > robust. Sort of like mercury concentrating in fish as it goes up the > food chain. And the kernel does a hash of all the entropy it is fed, > so even though that doesn't add entropy, we don't have the tools to > find the weaknesses spread out over 128 or 256 bytes. At least I don't > *think* there are tools capable of doing that. Maybe quantum tools > will have that capability, and hashes will have to be rethought. > > Here is the source for the daemon. > http://rtl2832-entropyd.sourceforge.net/ > i'll take a look at it, thanks! > If you are doing this, you might want to look at adding the bit-babbler > to rngd also. I considered it, but at ~ $100 it is a little pricey > and overkill for my needs. I would still have needed to find a way > to enter the entropy into the kernel, so I just went with the cheaper > option; an rtl2832 is about $10 on ebay, or was when I bought mine. > And more than adequate. > Yeah, I just ordered an RTL2832U from amazon for a few bucks, seems like a good cheap entropy source to make available. I'll try look into bit-babbler as well, but at $100, that might not be as worthwhile. > I think that any server farm or cloud provider that isn't using an > entropy device to reseed their crngs periodically is acting in > a criminally negligent manner with their customers' data. Especially > when it is so cheap. Even this $10 device is capable of reseeding > ~100,000 servers every 10 minutes or so. Sure, there would be some one > time development costs, but that's just a cost of doing business. > > That's why all this hand wringing over lack of entropy seems strange to > me. There are lots of adequate entropy devices, some expensive, some > reasonably priced, why isn't integration for them added instead of > deciding to just make do with crngs? We have network storage devices, > network time devices, why not network entropy devices? > Usually network entropy is avoided because its subject to manipulation from off system. You can hammer a target card enough that you can do enough prediction of interrupt timing to predict what the outcome will be. As for radio sources, I'm not sure. $10 is actually a huge cost on a BOM when you're building 1000's of systems, and crngs are cheaper, especially when an OS adds them anyway to handle the 'no hardware source' use case. Neil _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
