On Tue, 15 Aug 2017 10:07:27 -0400 Neil Horman <nhorman@xxxxxxxxxx> 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. 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. 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. 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_generators 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. _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
