A few years back, I came across some trick involving seeding entropy into Linux VMs to make them run faster. I still don’t fully understand how (think it has to do with the fact that a lot of activity does involve crypto functions): HackADay has a good write-up on that. Here are some details on how to make this work…

Update: this mostly applies to kernels older than 5.18. Linux 5.17 and 5.18 overhauled the kernel’s random number generator (and those changes were backported to the LTS kernels of the time), and entropy_avail is now effectively fixed at 256 — by design, not because your pool is starving. A 256-bit pool is enough to seed the kernel’s CSPRNG, /dev/random no longer blocks once it’s initialized, and haveged / jitterentropy-rngd / rngd won’t move that number. On a modern kernel, you can skip the steps below.

  1. cat /proc/sys/kernel/random/entropy_avail → a Linux system not running Kernel 5.6 or newer is probably going to be hovering around 1000 on this. Having the newer kernel seems to bump that up to between 2000 and 3000. (On 5.18 and later, this will always read 256.)
  2. Haveged was a good way to seed the entropy pool pre-5.6; that’s what got added into the kernel. The author recommends Jitter-RNG as an evolution of their work. On Debian/Ubuntu you can run apt install -y jitterentropy-rngd && systemctl restart jitterentropy-rngd to make use of this, even on a newer kernel; this seems to get you past 3000 on the pool. Online searches revealed versions of this for CentOS and Docker as well.
  3. rng-tools is a toolset that can be put to use on systems with newer hardware-based crypto. Redhat/CentOS/Fedora will have this as rng-tools package; Debian/Ubuntu has an rng-tools5 package you can install. Don’t try this in a VM; if it doesn’t work, uninstall it & try Jitter-RNG instead.

Happy crunching!