From Whonix

< Dev


Whonix ™ 14 has haveged installed by default. [1] (see below)

The Linux Kernel man page says: "[...] /dev/random should be suitable for uses that need very high quality randomness [...]".

Quoted from the 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.

Information resources[edit]


VirtualBox Bug Reports[edit]


As long as one entropy source of many is high quality, this foils attempts by adversaries to predict output and rescues the RNG.[2]

/dev/random vs. /dev/urandom[edit]

This debate comes from a misconception by the Linux manual writer.[3] 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.[4][5] 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.[6] 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:[7]

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 But fixing this configuration bug
has nothing to do with the /dev/random superstitions.

Software Packages[edit]


It has to be researched if they do work well inside Virtual Machines. Simply installing all of them may not be wise.


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.

The README in the haveged source folder and the haveged website contains instructions for testing haveged.

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/
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. [9]
  • 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.[10][11]


Playing devil's advocate here: Ted Ts'o [12] 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" [13]. 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[edit]

Entropy Key[edit]

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.



[advertisement] Looking to Sell Your Company? Contact me.

Have you contributed to Whonix ™? If so, feel free to add your name and highlight what you did on the Whonix authorship page.

https | (forcing) onion
Follow: Twitter.png Facebook.png 1280px-Gab text logo.svg.png Rss.png 1024px-Telegram 2019 Logo.svg.png

Share: Twitter | Facebook

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?)

Whonix ™ is a derivative of and not affiliated with Debian. Debian is a registered trademark owned by Software in the Public Interest, Inc.

Whonix ™ is produced independently from the Tor® anonymity software and carries no guarantee from The Tor Project about quality, suitability or anything else.

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. Whonix ™ is provided by ENCRYPTED SUPPORT LP. See Imprint.