On Wed, 17 Apr 2019 15:14:54 -0400 Steve Grubb <sgr...@redhat.com> wrote:
> Ah...the devil is in the details. It does not credit entropy. This > can easily be tested. systemctl stop rngd. Then open 2 terminal > windows. In one terminal start this shell script: > > #!/bin/sh > > while [ 1 ] > do > /bin/cat /proc/sys/kernel/random/entropy_avail > sleep 1 > done > > Then in another: > > cat /dev/random >/dev/null > > After a couple seconds, hit ctl-c to kill cat. Watch what happens to > the entropy. > > I have a Kabylake system idling. It takes 3 minutes for entropy to > get back to 3k after stopping the consumer. At that point its losing > about as much as its gaining. If I start rngd and do the same test, > my entropy bounces back to over 3k in less than a second. As it > stands today, rngd has a dramatic effect on entropy. I run a daemon that harvests entropy from the atmosphere via an rtl2832 and feeds it into the kernel via /dev/random. And, yes it makes a big difference to feed the entropy pool. When random.c was rewritten to use chacha instead of the modified mersenne twister (4.xx?), the way entropy was used changed. It used to bleed constantly across from the pool that is /dev/random into /dev/urandom when it was above the threshold set in write_wakeup_threshold. Now, it only checks when the kernel routine for get_random is called and reseeds if enough entropy is present. It always has decremented and still decrements entropy available when it uses some. Under mersenne it used to be possible to set a timer as well, but that went away with chacha. I patch to enable that feature in the new random.c, so I can reseed the chacha on a periodic interval. The rationale for chacha was that server farms were starving for entropy, and it is considered more robust for low entropy conditions, at least that is what I understand from my reading. As far as the CPU hardware entropy generators, those are not open source, so it is not possible to determine if they have a backdoor. Research has shown, however, that if any true entropy is fed into a stream with compromised entropy, it results in a stream with better entropy. That is, a system using a compromised hardware generator will have more robust entropy when combined with other sources of entropy. The kernel does this via a hash to smear the mix. An attacker can no longer utilize an attack knowing the bits came from the compromised generator. Things like the bit bubbler are reasonably cheap (~100 dollars US) and provide enough entropy for a small server farm. Even the rtl2832 (~10 dollars US) provides about 90 Kbytes of entropy per second (the kernel entropy pool is 4kB). Not enough for monte carlo simulations, but plenty for a home system or a few servers. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
