On Tue, Aug 15, 2017 at 08:59:24AM -0700, stan wrote:
On Tue, 15 Aug 2017 10:07:27 -0400
Neil Horman <nhorman(a)redhat.com> wrote:
> my bad, I thought when you said,
> the entropy pool just sits there, and they don't run.
> You meant your process was blocking (which would be bad for urandom),
> and thats the first thing that caught my eye.
> That said, what do you mean when you say "don't run". Do you mean to
> say the fips test exits on duplicate data, or that it runs, its just
> that the urandom crng doesn't seem to get refilled from the kernel
> entropy pool)
> If the latter is what you are concerned about I'd look at commit
> f5b98461cb8167ba362ad9f74c41d126b7becea7. I don't know what the last
> kernel you used was back when it worked the way you thought it
> should, but that commit converted the urandom generator such that it
> uses a pseudo entropy pool made up of a chacha20 cipher block to
> extract entropy from during reseeds instead of the kernel entropy
> pool it seems.
Yeah, I eventually got there. My quick perusal of the chacha20 cipher
leads me to the conclusion that it isn't really generating entropy,
rather that now another PRNG is feeding the kernel PRNG with pretend
entropy; bit fiddling doesn't generate entropy that isn't already there.
But I'm not an SME, just an interested amateur, so that could be a false
You're correct in your assertion, /dev/urandom isn't currently generating
entropy, but given that its designed to be non-blocking, its considered
sufficient to generate bit sequences that are non-deterministic and sufficiently
unpredictable for most use cases. If you need true entropy, then you need to
use /dev/random or some other hwrng. We do the same thing with the crypto
cprng, its frequently used to generate keypairs for ipsec tunnels.
Using conservative settings, the rtl2832_entropyd daemon can extract
kbits of entropy / second from atmospheric noise, and never runs out,
so I have no shortage of entropy. Thus my preference for the way things
used to work. The new way seems to be better for those without such a
copious supply, but worse for me.
That would be exactly the case, as most use cases are not like yours. Most
people just need a source of non-deterministic bits, and to do so quickly (virt
guests and the like).
I'm not sure what the kernel was when I really looked at this
it was probably in the 3 series kernels, or early 4s, before the 4.8
series. But I've noticed the entropy feeds being triggered by the
kernel, and thought I was seeing the old behavior. I had a problem
with the most recent alsa-lib interfering with the audio-entropyd
daemon because the card I was using wasn't recognized properly, and so
looked more closely again. I was probably seeing what I expected to see
based on my previous experience until I did look more closely.
That fits, the change to chacha20 was done around 4.10
> When I was looking at hardware RNGs, I looked at those listed on this
> My conclusion was that the bitbabbler was a good rng and good value; it
> seems to me that any one running a server farm who valued security
> could get it for < $50 US; 650 kbits/second can reseed a lot of PRNGs
> every 60 seconds. The rtl2382 is cheap and commodity, < $10 US on ebay,
> for personal use if someone didn't want to buy the bit babbler.
> I'd patch for the old PRNG behavior, but that is prone to future error
> that might be worse than accepting the new behavior if I miss future
> security flaws. Conclusion? Live with the new behavior; it helps
> that /dev/random is used for critical security numbers, and still
> accepts local entropy.