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?


closed as off-topic by CodesInChaos, DrLecter, poncho, K.G., fkraiem Apr 15 '15 at 7:52

  • This question does not appear to be about cryptography within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • $\begingroup$ can't you just get some output of /dev/urandom (of your hosting / deploying system) at VM creation time into a file in the VM and feed this file into the VM's /dev/urandom? $\endgroup$ – SEJPM Apr 9 '15 at 20:13
  • $\begingroup$ I suspect this is more of a question for Super User, or maybe Stack Overflow. But yes, in a sensible VM implementation, the guest OS ought to have some way to obtain entropy from the host (or at least have a seed file provided at start-up). $\endgroup$ – Ilmari Karonen Apr 9 '15 at 20:18
  • $\begingroup$ @SOJPM as I explained, it is a conceptual question. I believe it is perfectly possible and is one of the approaches I considered, but I don't know if it really is a problem and if this approach would be considered the best one. Then I thought some expert's opinions were in order to better document this possible issue for anyone that may run into it, myself included if I ever get to build such a system. :D $\endgroup$ – Fernando Cordeiro Apr 9 '15 at 20:18
  • $\begingroup$ @IlmariKaronen , I considered that, but since my worries are mostly about the cryptographic security of using such numbers I thought here would be best. If it is indeed a bad place to ask it I will be happy to move it somewhere appropriate. :D $\endgroup$ – Fernando Cordeiro Apr 9 '15 at 20:19
  • 4
    $\begingroup$ It's a general security question, not a cryptography question. It might fit security.se. $\endgroup$ – CodesInChaos Apr 12 '15 at 9:28

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):

  1. Make the VM-creating system (originally the backup system) PRNG aware -> let it update the PRNG's seed file.
  2. 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 :-( )
  3. Same as 2. but use a counter for each VM you create and hash that instead of the time. (again originally for backups)
  4. Provide entropy via a randomly generated seed file.
  5. 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.


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