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). 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. 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/ 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. 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? _______________________________________________ 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
