As mentioned in the PELD spec, it is not so easy to get good pseudo-random numbers in the context of a Live system. This document describes how Tails behaves in this area, and the work that is left to be done.
In addition to the Linux kernel's own entropy gathering facilities, Tails uses auxiliary entropy sources, that we describe below.
Tails ships HAVEGE, that
/dev/random whenever the supply of random bits in
/dev/random falls below the low water mark of the device.
Quoting its homepage, HAVEGE "exploits [these] modifications of the
internal volatile hardware states as a source of uncertainty".
The default configuration shipped with the
Debian package passes
-w 1024 to the
haveged daemon. That is, it sets
/proc/sys/kernel/random/write_wakeup_threshold to 1024.
We modify that
to use the same watermark as rngd, i.e. 2048 bits. The goal here is to
avoid the situation when rngd starts first and always keeps the
entropy pool between 1024 and 2048 bits, thus dominating the
rngd gets entropy from a hardware RNG, if available. Otherwise, it
does not start.
rngd fills up the pool using an
/dev/random to add
entropy. It does that unless
fill-watermark bits are available.
fill-watermark defaults to 50% of the size of the entropy pool,
which itself defaults to 4096 bits on Linux 3.14, so basically
feeds the entropy pool unless there are already 2048 bits in it.
The Debian package does not override this
default configuration, and neither does Tails.
rngd (2-unofficial-mt.14-1) does not modify any parameter in
ekeyd uses the Simtec Electronics Entropy Key, when available, to inject entropy into the kernel's pool.
haveged relies on the RDTSC instruction, that apparently is useless in some virtualized environments. Also, the quality of random numbers output by HAVEGE is unclear, and the topic of many discussions.
Further research on this topic is left to be done.
This is why Tails also ships
rngd. Still, it is not clear how these
two daemons act together.
It is not clear how much one can trust a hardware RNG, that is hard, if not impossible, to audit. Also, not all computers include a hardware RNG.
This is why Tails also ships HAVEGE. Still, it is not clear how these two daemons act together.
This discussion only makes sense whenever a hardware RNG supported by
rngd is available. Otherwise, only
haveged is used.
The way it is configured in Debian, haveged sets
/proc/sys/kernel/random/write_wakeup_threshold to 2048, so that
processes that are waiting to write to
/dev/random are woken up
whenever less than 2048 bits of entropy is available. In practice,
this probably means that Linux wakes up both
or less at the same time.
In such a case,
haveged tries to write as many bytes as needed to
fill the pool via a single
rngd tries to write 512
bits (the default value of
random_step being 64 bytes) at a time,
until the pool contains 2048 bits (default value of the pool water
mark). It's unclear which one wins the race. Let's discuss the
havegedalways wins the case, then it is actually useless to run
rngdalways wins the race, then it dominates the entropy pool, but shipping
havegedis still useful when no hardware RNG is available.
If the one that wins the race may change depending on the context, then it's still useful to ship both
haveged: it achieves our goal of not relying purely on either one.
This area is left to be researched.
On Debian Jessie, in the absence of any
(Tails ships no such file),
systemd-random-seed load, that won't write anything to
/dev/urandom (so we rely purely on the kernel and current system
entropy to get
This behavior is basically what Jake suggested earlier on this ticket, combined with #10779.
We've been in undefined behavior area forever: on Debian Wheezy, the
urandom initscript was seeding
/dev/urandom at boot time with the
date +%s.%N, concatenated with the content of
/var/lib/urandom/random-seed; this file was included in Tails ISO
images, and its content was fixed, public, and shared between
all -systems running a given Tails release.
So this can't be much worse, and the fact it's the new debootstrap and systemd default behavior tends to be somewhat reassuring.
Still, not persisting the state of the entropy pools between Tails boots seems to be wrong: #7675.
One should audit random numbers availability at early boot time: #6116.