Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

A really noob question, I know, but something I was wondering about this morning. If this were the case, would they encrypt things identically?

Or maybe someone could direct me to a helpful research about how linux generates entropy and encrypts things? Google is giving me tangential results but nothing especially helpful.

share|improve this question
I would hope that the clock has something to do with it, but in theory, I think one could recreate identical results. – George Bailey May 1 '12 at 13:51
This is a very interesting question, and the answer is not as clear-cut as you might expect. – Polynomial May 1 '12 at 14:31

3 Answers 3

up vote 16 down vote accepted

Identical system images will generate different data when pulling from their randomness pool unless you're working a very sterile setup to move them along synchronously one clock cycle at a time.

Activity in the system affects the randomness pool based on events including hardware interrupts. Reality says that disk drives, network cards, and the moment you pressed the power button will all vary. Even a well-disciplined clock will have some variance between machines and that will grow over time.

Some good readings include an academic paper on the Linux RNG and the random.c file from the current kernel source (intentionally unlinked).

share|improve this answer
The chaos multiplies over time, too. Small differences in the time it takes for a hard disk to satisfy swap IO and minor differences in clock speeds (not just on the CPU, but on the bus and all peripherals) will cause a cascade effect of unpredictability. This feeds into the randomness pool, which is then used in software. Once the differences reach a threshold that results in a single altered bit in the entropy pool, the output of /dev/urandom will change drastically. This might alter the order in which a thread is scheduled, or how long a loop takes, massively altering the machine state. – Polynomial May 1 '12 at 14:22
Once you start to take technologies such as ASLR into account too, you get a whole different ballgame. The randomness pool selects the base address of process modules, which will cause minor alterations in memory fetch latencies (especially when using swap) that go on to cause more changes in the entropy pool. When you factor various network statistics in there too, the difference between the two system states is amazing. – Polynomial May 1 '12 at 14:29
Until you are talking about virtual systems where the physical machine may lie to the virtual ones about when things happened, how long it took to access data, etc. – iheanyi Jan 15 at 21:59


The Linux RNG uses environmental sources of real entropy by gathering the noise from sources such as interrupt timing triggered by external hardware -- hard disk, mouse, network, etc. In fact, you could argue that Linux uses a "true random number generator" not a "pseudo random number generator" because the the output is truly unpredictable unless you can peek at the entropy source, just as it would be for any other TRNG.

There is a period of time, though, after a machine boots up from a known state before it has had the chance to gather any entropy from the environment during which the output of /dev/urandom would be predictable. is instructive and easy to understand.

share|improve this answer

The question is based on the false assumption that you can have two identical systems. That is not possible in this universe. For example, at a minimum, they would have to be in different places. Those different places will have different microscopic zone temperature variations. And those variations affect the phase relationship between the quartz oscillators that drive the CPU clock and the network clock.

Similarly, the microscopic surface defects in the disk platters and the inside of the hard drive case affect the turbulent shear of the air. This affects the rotation speed of the platters. There is no possible way you could have two hard drives with identical turbulent shear properties.

Even using the same clocks and the same hard drive, they'll still each issue their own requests. They'll still each receive their own network packets. They'll still each run their own separate path.

You would have to imagine a universe very different from ours for the question to even be asked. And yes, the Linux RNG algorithm does use these kinds of things.

share|improve this answer
You can have two identical systems. We're talking about virtual machines here. It may be hard to achieve with fast VMs that rely on hardware virtualization, but with a pure hardware emulator, it's easy. – Gilles May 2 '12 at 18:49
@Gilles: Identical VM images do not make identical systems. Even if they run on the same physical machine, they run at different times, where the quartz oscillators have different temperatures and the disk platters have different rotational speeds. You can only make them the same if you fully simulate everything the vm has access to (for example, precisely synchronizing all input down to the clock cycle), and such a system bears no resemblance to any realistic system. (And, so far as I know, there exists no method to do it with an actual Linux system.) – David Schwartz May 2 '12 at 19:26
Clock-accurate emulators do exist. They aren't used so much by sysadmins (who prefer VMs that run at a decent speed), mostly by OS developers. But in, say, a reverse engineering context, you can't dismiss them out of hand. – Gilles May 2 '12 at 20:23
True, but you can't actually use such systems. The moment you feed them any input by any kind of realistic method, they cease to be clock accurate. But in any event, the question wasn't about clock accurate emulators (at least, nothing suggested it was). It was about ordinary VMs. – David Schwartz May 2 '12 at 21:52

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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