On Debian (and I guess on other linux distributions as well), there is an init script /etc/init.d/urandom, whose function it is to:

"Save and restore random seed between restarts"

In my case, this file is saved to /var/lib/urandom/random-seed.

I wonder how wise it is to save random seed to a file on disk, when the whole assumption of random seed in cryptography is that is kept secret.

Why do that at all, in the first place. Do we need to "preserve" the random seed between restarts ? What would happen if we don't? Will the computer have 0 randomness when it boots?


Why do that at all, in the first place. Do we need to "preserve" the random seed between restarts ? What would happen if we don't? Will the computer have 0 randomness when it boots?

This turns out to be a much deeper question than you might realize. I'll try to do justice to it without writing a textbook.

Basically: computers suck at randomness; when you have some true randomness (aka entropy), it's a good idea to hold on to it.

Let's assume that your computer doesn't have a hardware random number generator. (Modern Intel chips have the rdrand instruction that taps into a hardware rng, but for political reasons, the Linux kernel doesn't use it.)

On boot, where does the kernel get pure randomness from? According to Wikipedia:

The Linux kernel generates entropy from keyboard timings, mouse movements, and IDE timings and makes the random character data available to other operating system processes through the special files /dev/random and /dev/urandom. This capability was introduced in Linux version 1.3.30.

So mouse, keyboard, and timing of harddrive IO events. Let's say you need entropy during OS boot (for example you start sshd which needs to generate keys on its first startup), you haven't loaded the mouse and keyboard drivers yet, and that early in the boot cycle you won't have made very many disk IO calls -- hell, early enough in the boot the kernel is still running in a RAM FS, and even after that you may be on an SSD or flash drive that has very predictable IO times.

So back to your question:

What would happen if we don't? Will the computer have 0 randomness when it boots?

It's possible.

On small embedded linux devices like routers that boot out of flash memory (both the small home ones, and the big datacentre ones that power the internet), this is actually a serious problem.

For an awesome read on this topic, see the 2012 paper Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices which has the shocking finding that

0.75% of TLS certificates [on the internet] share keys due to insufficient entropy during key generation.

  • could you please elaborate on why linux does not use the rdrand instruction ? – Martin Vegter Jul 10 '17 at 14:34
  • @MartinVegter Good question. It's political: the linux kernel devs are worried that, since Intel is an American company, the NSA might have forced them to backdoor the rdrand chip. Intel has publicly denied this, but they have no way to prove it. So we're at a political stalemate. – Mike Ounsworth Jul 10 '17 at 14:51

Just a few lines below the Short-Description you quoted, /etc/init.d/urandom notes some assumptions about the secrecy:

## Assumption 1:  We assume [/var/lib/urandom/random-seed] is a file (or a symlink
## to a file) that resides on a non-volatile medium that persists
## across reboots.
## Case 1a: Ideally, it is readable and writeable.  Its is unshared,
## i.e. its contents are unique to this machine.  It is protected so
## that its contents are not known to attackers.
## Case 1b: Less than ideally, it is read-only.  Its contents are
## unique to this machine and not known to attackers.

Later in that file, where the seed is written to disk, there is a comment:

# see documentation in linux/drivers/char/random.c

which is worth reading but includes:

* When any operating system starts up, it will go through a sequence
* of actions that are fairly predictable by an adversary, especially
* if the start-up does not involve interaction with a human operator.
* This reduces the actual number of bits of unpredictability in the
* entropy pool below the value in entropy_count.  In order to
* counteract this effect, it helps to carry information in the
* entropy pool across shut-downs and start-ups.

... Even with
* complete knowledge of the start-up activities, predicting the state
* of the entropy pool requires knowledge of the previous history of
* the system.

Saving entropy between reboots is an imperfect solution to boot-time entropy shortages. Why imperfect? First, because saved entropy is discoverable, if potential attacker could get a hold of that saved seed they could also compromise all random number generators seeded with it. Second, because when system is restored from backups or multiple VM instances spawned with the same saved seed they would all reuse the same saved entropy.

Still, such disasters are still preferable to having no boot-time entropy available to your system.

Keep in mind, if you configure to save entropy your solution will not be certifiable, as FIPS and pretty much any other crypto and infosec related standard prohibits this practice.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.