00RANDOMNESS IN COPIED MACHINES

Clones can
repeat themselves.

A long aisle of identical server racks with small status lights in a quiet data centre — AI-generated image, not a photograph of a real person or place.

Copy a running computer and you copy its dice too.

A virtual machine snapshot saves everything, including the state a system uses to make random numbers. Run two copies from the same point and both may roll the same numbers, which matters because encryption relies on randomness nobody can predict.

SAME STATEsame 'random' numbersUpdated 16 October 2026

Check a scenario

01Principles

Snapshots save the dice
Copies roll alike
Reseed after restore
Fresh randomness for every copy

02THE SHORT ANSWER

Good keys,
bad randomness.

Encryption can fail even with strong keys
if the randomness is used twice.

REPLAY

One snapshot, run twice

University researchers showed that running a virtual machine twice from the same snapshot made secure web connections reuse the same randomness, enough to expose one server's secret signing key.

Check a scenario

SHARED KEYS

Keys baked into an image

SSH host keys are meant to identify one specific machine. Many images ship with default host keys, so every copy made from them can present the same identity unless the keys are replaced.

Before you clone

RESEEDING

Telling a clone it is a clone

A VM Generation ID changes when a snapshot is applied or a backup restored. Linux uses it from kernel 5.18 to reseed its random number generator straight away.

See the numbers

03A QUICK SCENARIO CHECK

How likely is a
repeat after copying?

Pick a situation to see how much risk of repeated randomness or shared secrets the sources describe. The bar shows the level of concern.

Based on Ristenpart and Yilek (NDSS 2010), Firecracker's 'Entropy for clones' guidance, and the cloud-init module reference.

Scenario check

Choose a scenarioResuming one snapshot more than onceMany copies of an image with built-in SSH host keysA saved random-seed file left in the snapshotRestoring on Linux 5.18 or later with VM Generation IDProcessor with built-in random number instructions

Resuming one snapshot more than onceRepeats seen

Researchers showed key exchange and signing reusing randomness when a VM ran twice from the same snapshot, in both of the virtual machine managers they tested.

Many copies of an image with built-in SSH host keysShared identity

Host keys authenticate a specific instance. If the image's default keys are kept, every copy holds the same private key; cloud-init can remove them with ssh_deletekeys.

A saved random-seed file left in the snapshotRemove it

Firecracker's guidance says to delete files such as /var/lib/systemd/random-seed before taking a snapshot, so no clone reuses them.

Restoring on Linux 5.18 or later with VM Generation IDAuto reseed

The kernel reseeds when it handles the notification, but there is a short race window between the copy resuming and the reseed.

Processor with built-in random number instructionsExtra mixing

Firecracker says hardware-supported reseeding on recent processors should be sufficient for most cases, though it still recommends the steps above.

Sources: Ristenpart and Yilek, When Good Randomness Goes Bad (NDSS 2010); Firecracker docs, Entropy for clones; cloud-init module reference (host keys).

04TWO NUMBERS WORTH KNOWING

Repeated randomness
is not rare.

A survey of real keys on the internet,
and the kernel version that reseeds clones.

9.60%

SSH hosts sharing public keys in an apparently vulnerable way

Due to weak randomness during key generation or default keys. Most were embedded devices that make keys on first boot; the figure for TLS hosts was 5.57%.

INTERNET SURVEY · UC SAN DIEGO AND U. MICHIGAN

5.18

First kernel version that reseeds on a VM Generation ID change (ACPI systems)

After the notification is handled, clones from one snapshot get distinct random output. DeviceTree systems gained support in 6.10.

LINUX KERNEL · VMGENID

Sources: factorable.net, Widespread Weak Keys in Network Devices; Firecracker docs, Entropy for clones.

05WHAT THE GUIDANCE SAYS

Give every copy
its own randomness.

These are the steps the cited documentation describes for images and snapshots that will be copied.

Remove built-in host keys
Many images carry default SSH host keys. cloud-init can delete them with ssh_deletekeys and, if none are supplied, generates a new pair of each key type for the instance.
Clear saved seeds
Delete random-seed files such as /var/lib/systemd/random-seed before taking a snapshot that will be cloned.
Use VM Generation ID
Hypervisors and guests that support it (from Windows 8 and Windows Server 2012, and Linux 5.18) let the guest detect that a snapshot or backup was applied.
Reseed before code runs
For the strongest protection, Firecracker suggests adding fresh entropy and forcing a reseed before applications resume in the clone, and attaching a virtual random number device.

A handful of white dice scattered across a dark wooden table in soft light — AI-generated image, not a photograph of a real person or place.

06WHY IT MATTERS

Fresh dice,
every time.

Two identical brass keys lying side by side on a plain wooden desk — AI-generated image, not a photograph of a real person or place.

Routine cryptography such as encryption and signing can fail badly if the same randomness is used twice, even with good long-term keys. Ristenpart and Yilek demonstrated session compromise against two major web browsers and recovered a web server's DSA secret key, letting an attacker impersonate it.

Their fix was to 'hedge' cryptographic operations against bad randomness, which they applied to a widely used open-source library with little overhead. Firecracker's guidance adds that some applications keep their own randomness pools, which kernel reseeding does not reach.

07Questions

Questions people ask

Why would two cloned VMs produce the same random numbers?

A snapshot captures the whole machine, including the state of its random number generator. If two copies resume from that point before fresh randomness is mixed in, they can produce matching values.

Has this caused real security problems?

In research, yes. Ristenpart and Yilek showed attacks on secure web connections when a VM ran twice from one snapshot, including recovering a server's DSA signing key.

What is a VM Generation ID?

An identifier that changes when a snapshot is applied or a backup is restored, so software inside the VM can detect the time shift. Windows 8 and Windows Server 2012 introduced support.

Does Linux handle cloned VMs automatically?

Since kernel 5.18 on ACPI systems, Linux uses the VM Generation ID to reseed its random number generator, though a short race window remains straight after resuming.

Why do SSH host keys matter for clones?

Host keys authenticate a specific machine. Copies made from an image that contains default host keys all share the same private key unless the keys are deleted and regenerated.

08Sources

Clones can
repeat themselves.