On Tue, 15 Aug 2017 13:50:49 -0400 Neil Horman <nhorman@xxxxxxxxxx> wrote: > On Tue, Aug 15, 2017 at 08:59:24AM -0700, stan wrote: > > On Tue, 15 Aug 2017 10:07:27 -0400 [snip] > 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. [snip] > > 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. I decided to patch to use some of the entropy I have. I first refreshed my understanding of the random number generation in the kernel, the below is a good overview. https://pthree.org/2014/07/21/the-linux-random-number-generator/ Then I created a patch that uses the old urandom_min_reseed_secs variable to determine how often the crng in the kernel should be reseeded from entropy. And a new function to reseed that often, as long as there is enough entropy in the input pool (>= 4000 bits, out of a maximum size of 4096). I then compiled the latest 4.13 kernel with that patch applied, and it seems to be working just fine. It puts a message into the journal every time it reseeds, and I eventually went back to the stock kernel default of 5 minutes. The default in the patch is 1 minute, and I was reseeding previously every 5 seconds. That worked but seems like overkill. /usr/bin/echo 300 > /proc/sys/kernel/random/urandom_min_reseed_secs I've attached the patch for anyone who has an external source of entropy feeding the kernel entropy input pool, and wants to reseed the crng in the kernel periodically. If you decide to do this, you'll have to put this in the kernel.spec file: # use entropy from input pool based on level and time to reseed crng Patch1000: 1000-use-input-entropy-to-reseed-crng-based-on-timer-and-.patch Here's a page that explains how to generate a patch for a Fedora src.rpm from the git repository. https://www.hiroom2.com/2016/06/25/fedora-24-rebuild-kernel-with-src-rpm/ These are the official pages for how to build a custom kernel in Fedora. https://fedoraproject.org/wiki/Building_a_custom_kernel https://fedoraproject.org/wiki/Building_a_custom_kernel/Source_RPM _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
