Randomness in generation of Virtual Machines from pre-built Image I am studying Multi-Tenancy vs. Virtualization, and I got thinking about randomness, true randomness, virtualization etc, and I couldn't find anything on it.

From what I gather, /dev/urandom is just as good as /dev/random and you should use it instead, BUT... it doesn't bloc if you "don't have enough entropy"... That has been extensively discussing before and there is a consensus that /dev/urandom is more than enough for everyday usage.

But if I am creating virtual machines on-demand from a single image, with the whole deploy process automated (Thus replicating all the steps and possibly durations for each step), won't this mean very little entropy...?

I read about seeding VMs to get more entropy, but is that approach feasible, has it been done, is there some/any consensus on this?

This is a conceptual question, I have no specific implementation I'm working with, I  just want an outline about this possible issue where lack of randomness can possibly be seen in everyday usage (Or if I am mistaken, which is very possible), and if there is consensus how one should approach this possible scenario.

I'm trying to imagine something uses VMs based on a single image, and it gets so big that it becomes "rewarding" to build something akin to a "rainbow table", in the sense of using this "not-so-random" starting pool that is the same for all VMs to find out any and all possible encryption keys/hashes/etc used for securing said installation, thus being able to break into a system, provided the attacker had access to the algorithm and images used to generate the system, and that he has access to the result of said encryption.

If an attack like that is even possible, what would be risk level of that? Would it be better to re-hash everything or something after gathering enough entropy on the new VM, possibly by using something like /dev/random, or even then it is a bad choice...? What about seeding this machine with entropy...?

How should one approach this problem, if it is indeed a problem?
Low entropy for PRNGs is bad.
If you set up a VM by automatized software, you won't have entropy for your PRNG which is not good.

What would be the risk level? Weak cryptographic keys (pretty bad if this is f.ex. a SSH log-in key or someting like this).

Seeding the VM with entropy rich data from the host is the standard solution and will solve the problem.

In my edition of "Cryptography Engineering: Design principals and Practical Applications by Schneier, Fergueson and Kohno" the following solutions are described (for seeding the Fortuna-CSPRNG):


Make the VM-creating system (originally the backup system) PRNG aware -> let it update the PRNG's seed file.
Hash the current time. (originally, again backup system: hash the current time along with the seed file). This works unless the clock's reset and will prevent the PRNG from outputting the same bits. (no high entropy :-( )
Same as 2. but use a counter for each VM you create and hash that instead of the time. (again originally for backups)
Provide entropy via a randomly generated seed file.
Just wait for random events to take place. (if your PRNG implementation is good you can't fully reproduce things like RDRAND output or hard-drive noise) This might take some time and should be last line of defense.


Conclusion: Entropy feeding from the outside is the best option.

I hope this gives you some answers.