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?