On Tue, Aug 15, 2017 at 08:59:24AM -0700, stan wrote: > 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. > 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_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
