On Tue, Aug 15, 2017 at 08:59:24AM -0700, stan wrote:
On Tue, 15 Aug 2017 10:07:27 -0400 Neil Horman nhorman@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)
The latter.
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 conclusion.
You're correct in your assertion, /dev/urandom isn't currently generating true 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 ~90 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 last, 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 page, https://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generator... 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.