# Entropy on virtual machines

As you might know that it's not as easy to generate entropy on a virtual machine as on a "normal" pc. Generating a gpg-key on a virtual machine can take a while, even with the correct tools.

There are plenty more crypto functions out there which aren't so entropy aware as gpg is.

So can one say that cryptography is less secure on a virtual machine?

-
Random numbers from a "real" machine aren't actually random to begin with (unless you have a hardware random number generator, which most do not). They're all pseudo random to begin with, and entropy is generated the same way. If it's slow on a VM, it's the virtualization platform slowing it down (I'd venture a guess you're not using a Type 1 Hypervisor). – Chris S Oct 24 '11 at 12:45

Not really.

Entropy is only required for random operations. The only random operation in pretty much any cryptography system is key generation. After that, the math is all very codified based on the plaintext and the key, with no truly random elements otherwise it would be rather difficult to reverse it again. Even hash algorithms aren't random, they are functions in the mathematical sense: they map a given input to a specific, repeatable output.

If you're really worried, then generate your keys on real boxes. But beyond that, there's no real reason to worry about entropy affecting crypto-systems.

-
Actually, most asymmetric signature and encryption algorithms also use a bit of random data. Though a cryptographic strong PRNG will be enough here. – Paŭlo Ebermann Oct 24 '11 at 12:23
As Paulo mentions, basically every crypto system in use today starts a session by both ends picking a random number, doing some math (possibly with keys) and coming up with a new number. – Chris S Oct 24 '11 at 12:43
@PaŭloEbermann: PRNG's are not random! Given the same seed, they will produce the exact same string of 'random' numbers, which is why they are able to be used for crypto. PRNG's and entropy are two totally different beasts. Entropy is generated from various events on the system and is unable to be repeated, which is what makes it useful for key generation, though generally more or less useless for the rest of crypto. – Matthew Scharley Oct 24 '11 at 21:10
@Matthew Please have a look at What is the use of REAL random number generators in cryptography? for a list of cryptographic uses for which one does not need a deterministic pseudo-random number generator, but a (good) pseudo-random one will still be enough (given enough entropy on the initialization). The determinism of PRNGs is not that often needed (and if so, then they are usually called "stream cipher"). – Paŭlo Ebermann Oct 24 '11 at 21:18
There are also some signatures that require random data, such as DSA. The simplistic answer that it is only for generating keys is wrong. – Michael Graff Feb 22 '13 at 3:33

First of all, let me say I'm not at all a security expert.

As gpg key creation is using `/dev/random` as random number generator, it is as secure on a virtual machine, as on a real machine.
`/dev/random` is a blocking device, and will stop delivering any randomness beyond the available amount. You can check your available randomness by
`cat /proc/sys/kernel/random/entropy_avail` (should be around 2000)

On a virtualmachine the available randomness is indeed lower than on a real machine, due to the lacking access to hardware.
You could increase the entropy by e.g. applying entropy keys and/or switch to a nonvirtualized machine.

There is a nice article available on entropy on virtual machines. Unfortunatly both parts of the article are only available in google cache right now.

Entropy has further effects on any ssl/tls encryption. So, using `/dev/urandom` or any not-truly random source has indeed an impact on the security of your applications.

In terms of how reliable `/dev/urandom` compared to true randomness is;
i'm not able to give you a decent answer there, sorry.

-
`/dev/urandom` is using a cryptographically secure PRNG (seeded by the same pool as `/dev/random`), so there should be no problem as long as there was enough initial entropy in this pool. There might be a point in seeding it from the parent machine's entropy pool. – Paŭlo Ebermann Oct 24 '11 at 12:25

Yes, under most circumstances cryptography is less secure on a virtual machine than on a "real" server.

The latter can at least gather entropy from some actual hardware. In fact, the operation of a piece of HW is - in most cases - bound to some physical phenomenon, which is always subject to small variations, random by all accounts. Since servers typically run for a very long time without a reset, the resulting entropy pool will eventually be of sufficient quality.

Virtual machines suffer from three problems.

1. The hardware they see is not real, and therefore it is hardly influenced by any physical phenomenon. They will be able to collect entropy in a much slower manner.
2. VMs are reset much more often than real servers and they may not even have time to collect enough entropy (which is why it is good to save the current entropy state when shutting down, and use it to feed the entropy pool when restarting).
3. While a real server may have some chance to determine when it is dealing with a bad entropy pool, the virtual machine will more easily operate under the impression the entropy pool is good (because it was collected from HW, but without knowing that the HW is not real), whereas it is actually bad.

The best solution is to have the VM to simply give up and realize that the HW it sees is a bad source of entropy. Then, arrange a local network service for distributing high-quality entropy (see Entropy Broker). The "entropy server" may extract randomness from generic HW (in which case it must operate for a sufficient time, and it must have a decent OS) or from specific crypto HW (a TPM chip, a VIA Padlock chip, etc).

A VM using such a service may even be more secure (cryptographically-wise) than a "real" server that has just booted up.

-