Actions

Dev/Entropy

From Whonix

< Dev


Introduction[edit]

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

Quoted from the riseup.net page about entropy [archive]: "[...] 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.

User space (not kernel space) entropy failures:

Quality[edit]

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

RDRAND[edit]

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

Viewpoint: /dev/random is obsolete[edit]

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

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

Viewpoint: better use /dev/random[edit]

By Whonix ™ developer Patrick.

Here is what renown cryptographer Dr. Daniel J. Bernstein has to say on the matter [6]. The quote was cut to simplify things.

[...] but Linux /dev/urandom ([...]) spews predictable data [...]

Quote without cutting the parentheses. (Underline is mine. code is mine.)

[...] but Linux /dev/urandom (unlike Linux /dev/random) spews predictable data [...]

Oversimplified interpretation:

  • He's saying that /dev/random does not spew predictable data.
  • In other words, he's saying that /dev/random produces random data.
  • He's saying that /dev/urandom spews predictable data.

Quoting whole paragraph.

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

Interpretation:

  • He's saying that /dev/urandom spews predictable data if the randomness pool has never been initialized.

A randomness pool that has never been initialized is an issue in many cases:

  • first boot
  • inside virtual machines
  • first boot inside virtual machines
  • golden images without random seeds
  • golden images coming with published, shared (among all users of the golden image) random seeds

The issue of randomness pool initialization is well elaborated at systemd Random Seeds [archive].

Finally, I need to address what my interpretation is what he means by "superstitions". Quote:

the /dev/random superstitions.

Related paragraphs. Quote:

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.

Interpretation: He is only talking about people who think that /dev/random should always be used. Should always be considered more secure. Even in cases where randomness pool initialization is done. That is superstitious and I think that is a fair argument. The problem is, that it is non-trivial to know the status of randomness pool initialization. Therefore that is a rather theoretic consideration.

Quote systemd Random Seeds [archive]:

(Strictly speaking there are more APIs, for example /dev/random, but these should not be used by almost any application and hence aren’t mentioned here.)

This could use some elaboration. Hence, asked, see systemd feature request: systemd.io/RANDOM_SEEDS - elaborate on /dev/random [archive]

My conclusion is:

  • Prefer using /dev/random whenever security is important such as for key generation.
  • /dev/random provides higher quality assurance than /dev/urandom. No conditionals.
    • /dev/urandom might be OK depending on randomness pool initialization.
    • /dev/random is OK either way.
  • This is specifically important at early boot when it's non-obvious if randomness pool initialization is done yet.
  • How to check the status of randomness pool initialization? Non-trivial.
  • Just make sure that /dev/random produces enough random data which is doable nowadays thanks to these software packages listed on this page.
  • /dev/urandom might be providing the same level of entropy quality as /dev/random does, but due to the previous point, for simplicity, there is no reason to use /dev/urandom.

My simplified conclusion is:

  • Use jitterentropy-rng kernel module, jitterentropy-rng user space daemon, haveged and whatnot.
  • And then simply use /dev/random.

Proponents of the viewpoint that "/dev/random is obsolete, use /dev/urandom, always" should explain:

  • Why Linux offers both, /dev/random and /dev/urandom and why if it is "really the same" isn't just a symlink from the one to the other.
  • Why Linux does not use the same code paths for /dev/random and /dev/urandom? Why have this distinction in the first place?

Kernel developer Theodore Y. Ts'o in 2019: https://lore.kernel.org/linux-ext4/20190915052242.GG19710@mit.edu/ [archive]

Software Packages[edit]

Introduction[edit]

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

haveged[edit]

Haveged is an entropy gathering daemon.

Quoted from the haveged testing page [archive]: "[...] 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 [archive] contains instructions [archive] 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/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. [8]
  • This was successfully tested in Qubes with haveged running.

Installed by default in Whonix ™.

jitterentropy[edit]

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

Links:

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

kernel module added (Whonix ™ 15.0.0.7.2) and above:

randomsound[edit]

https://forums.whonix.org/t/moar-entropy-sources/8543 [archive]

Hardware Entropy Keys[edit]

Entropy Key[edit]

Entropy Key [archive]; 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[edit]

OneRNG [archive]; 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.

List[edit]

VirtualBox Bug Reports[edit]

Resources[edit]

Footnotes[edit]



Follow: Twitter.png Facebook.png 1280px-Gab text logo.svg.png Rss.png Matrix logo.svg.png 1024px-Telegram 2019 Logo.svg.png Discourse logo.svg

Donate: Donate Bank Wire Paypal Bitcoin accepted here Monero accepted here Contriute

Whonix donate bitcoin.png Monero donate whonix.png

Share: Twitter | Facebook

Join us in testing our new AppArmor profiles [archive] for improved security! (forum discussion [archive])

https [archive] | (forcing) onion [archive]

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 [archive] of the Open Invention Network [archive]. 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 [archive]. Debian is a registered trademark [archive] owned by Software in the Public Interest, Inc [archive].

Whonix ™ is produced independently from the Tor® [archive] anonymity software and carries no guarantee from The Tor Project [archive] 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.