Whonix ™ 14 has haveged installed by default.  (see below)
The Linux Kernel man page says: "[...] /dev/random should be suitable for uses that need very high quality randomness [...]".
Quoted from the riseup.net page about entropy: "[...] entropy-estimation is a black-art and not very well understood [...]".
While it would be good to be cautions, i.e. learning about the entropy quality in Virtual Machines and if required learning about methods to improve it, it is not a critical problem. Successful entropy estimation attacks have never been reported for any software.
- Gentoo wiki: Generating better random numbers
- HAVEGE: PolarSSL Security Advisory 2011-02
- Qemu: virtio-rng, virtual random generator
VirtualBox Bug Reports
As long as one entropy source of many is high quality, this foils attempts by adversaries to predict output and rescues the RNG.
/dev/random vs. /dev/urandom
This debate comes from a misconception by the Linux manual writer. The fact is both APIs use the same CSPRNG. The issue happens when the randomness pool has not been properly initialized and entropy is requested early at boot. Otherwise the blocking behavior of
/dev/random during normal system running is an annoying bug than a useful safety feature. A well seeded pool should be able to provide sufficient/endless randomness from a single seed. There is no concept of entropy being used up when urandom is used unlike random that nonsensically calculates left over entropy and blocks despite a healthily initialized pool. Therefore rate limiting virtio-rng is unnecessary when using urandom as a backend.
Here is what renown cryptographer Dr. Daniel J. Bernstein has to say on the matter:
Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that (1) we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but (2) we _can_ figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.). For a cryptographer this doesn't even pass the laugh test. I'm not saying that /dev/urandom has a perfect API. It's disappointingly common for vendors to deploy devices where the randomness pool has never been initialized; BSD /dev/urandom catches this configuration bug by blocking, but Linux /dev/urandom (unlike Linux /dev/random) spews predictable data, causing (e.g.) the widespread RSA security failures documented on http://factorable.net. But fixing this configuration bug has nothing to do with the /dev/random superstitions.
It has to be researched if they do work well inside Virtual Machines. Simply installing all of them may not be wise.
- entropy broker: In Debian.
- rng-tools: In Debian.
- timer_entropyd: Not in Debian.
- audio-entropyd: Not in Debian. Confirmed by author to not cache audio input same for video.
- video-entropyd: Not in Debian.
- clrngd: Not in Debian? But replaced by haveged / jitterentropyd?
- ekeyd: In Debian.
- HAVEGED: In Debian. See below.
- jitterentropy-rngd: In Debian. See https://phabricator.whonix.org/T817 and below.
Haveged is an entropy gathering daemon.
Quoted from the haveged testing page: "[...] will behave similarly in a virtual environment is a more risky proposition [...] there have been reports of VM that implement the processor time stamp counter as a constant and there are known differences in cpuid operation in others. [...]"
Will haveged create sufficient entropy in VirtualBox? Luckily, haveged comes with tools to check the if the entropy it creates.
Makes sense to test entropy while haveged is disabled.
sudo service haveged stop
Get haveged sources and test.
apt-get source haveged cd haveged-* ./configure --enable-nistest make check ## perhaps repeat #make clean #make check
Should say something like
0 failed individual tests PASS: nist/test.sh ================== All 2 tests passed ==================
- This was successfully tested in VirtualBox without haveged running.
- This was successfully tested in VirtualBox with haveged running.
- This was successfully tested in kvm without rng device and without haveged running.
- This was successfully tested in kvm without rng device and with haveged running.
- This was successfully tested in Qubes without haveged running. 
- This was successfully tested in Qubes with haveged running.
jitterentropy is a RNG designed in the spirit of haveged (using CPU timer jitter as entropy source) except it made up of a kernel module - mainlined since Linux 4.2 and a userspace daemon (jitterentropy-rngd*) to prevent /dev/random from blocking. The advantage of jitterentropy is by taking advantage of a loaded kernel module, it can ensure randomness is being collected before the CSPRNG is initialized. So, when CSPRNG initialization happens, we can ensure that it is properly seeded on first boot, minimizing the likelihood that exact keys will be created on distinct systems. This is something haveged can't provide, as it runs entirely in userspace.
It is a good alternative to haveged, especially for hypervisors that don't support virtio-RNG and so don't have access to entropy sources early during boot process. jitterentropy-rngd is now included in Debian Buster and has been available since Whonix ™ 15.
Playing devil's advocate here: Ted Ts'o  expresses strong skepticism about the efficacy of RNGs that rely on CPU jitter. summary: CPU jitter may not be random as thought to someone who designed the CPU cache and know how its internals "tick" . So while these RNGs may not harm, another solution for RNG-less platforms may be a good idea.
It may be that there is some very complex state which is hidden inside the the CPU execution pipeline, the L1 cache, etc., etc. But just because *you* can't figure it out, and just because *I* can't figure it out doesn't mean that it is ipso facto something which a really bright NSA analyst working in Fort Meade can't figure out. (Or heck, a really clever Intel engineer who has full visibility into the internal design of an Intel CPU....)
Hardware Entropy Keys
Entropy Key; Hardware not fully open source. Some resources say, it is okay as an additional source of entropy. Where to add it? Since Whonix ™ depends on a host operating system, the Whonix-Gateway ™ and the Whonix-Workstation ™, where it does make most sense to add it? Perhaps adding it to the host and using a entropy broker could be the most effective method. Better than buying three entropy keys.
OneRNG; Hardware and Firmware fully open source. Firmware is cryptographically signed to ensure it hasn't been tampered with. Board has a removable tin RF Shield so you can verify the circuits match the diagrams provided by the manufacturer. Fully reprogrammable with manufacturer provided software+cable (must be bought separately). Where to add it? Since Whonix ™ depends on a host operating system, the Whonix-Gateway ™ and the Whonix-Workstation ™, where it does make most sense to add it? Perhaps adding it to the host and using a entropy broker could be the most effective method.
- Random Sequence Generator based on Avalanche Noise
- turbid - High-Entropy Symbol Generator http://www.av8n.com/turbid/
- turbid - Debian RFP - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=59147
- On Linux entropy issues generally. Must read. - https://www.av8n.com/computer/htm/secure-random.htm
This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation.
Copyright (C) 2012 - 2019 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)
- Since Whonix ™ 0.5.5 and above.
- Peter Gutmann of secure erasure fame https://www.metzdowd.com/pipermail/cryptography/2019-September/035329.html
- https://news.ycombinator.com/item?id=11561340 Comments by tptacek
- He's the main developer behind Linux's RNG and staunchly resisted relying only on Intel's RDRAND. His opinions carry weight with good reason.