On Tue, Feb 25, 2020 at 09:27:07AM -0700, stan wrote:
On Tue, 25 Feb 2020 08:17:37 -0500
Neil Horman <nhorman(a)redhat.com> 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