Entropy on virtual machines

Solution 1:

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.

For further information about this topic you could go to http://security.stackexchange.com and/or read eg. this post

Solution 2:

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.