There are even bigger concerns with crypto on virtualized hardware: side channels. We probably don't even know all the microarchitectural pathways that crypto code can leave footprints on, let alone how to deploy efficient general-purpose crypto code to obscure those footprints.
Could you elaborate on this? My interesting stuff detector is going crazy but I'm kinda out of my depth as to what exactly you're talking about. Are you referring to information leakage from the guest to the host operating system that might allow the host to sniff the inner workings of crypto algorithms running on the guest? Or perhaps guests sniffing other guests through timing attacks and suchlike?
In a previous job I worked for a company whose product needed some entropy on startup. It originally read from /dev/random. But then one of our customers reported that the product was hanging on startup, just after installation. It turned out that they had installed it into a freshly built VM (not a cloned one, I guess) and the read from /dev/random was waiting to accumulate enough entropy to return. (We changed it to use /dev/urandom instead, which is not entirely satisfactory, but at least prevents hanging in this situation.)
While this is not exactly the scenario the OP is describing, it's another thing that can go wrong with /dev/random and VMs.
For servers and VMs without much internal entropy, they could use a random number server. On boot, they could pull random seed data from a web service like random.org or by hashing Google News headlines.
Most servers have little source of decent entropy. Virtualisation makes this worse. Intel has dropped the motherboard RNG support in their chipsets. The suggestion in the thread to use a few cheap VIA boxes which have CPU RNG is one idea. There are cheap USB rngs too like http://www.entropykey.co.uk/.
I did some research work last semester on crypto inside VMs. One of our initial readings was Yilek's work on attacking VM crypto through VM snapshots http://cseweb.ucsd.edu/~syilek/ndss2010.html
That's an interesting trick but not really representative of the problem. Reusing an RNG's entropy pool wholesale after restarting a snapshot is a mistake, not a design flaw.
[+] [-] tptacek|15 years ago|reply
[+] [-] JonnieCache|15 years ago|reply
[+] [-] ScottBurson|15 years ago|reply
While this is not exactly the scenario the OP is describing, it's another thing that can go wrong with /dev/random and VMs.
[+] [-] nodata|15 years ago|reply
[+] [-] cpeterso|15 years ago|reply
[+] [-] justincormack|15 years ago|reply
[+] [-] stipes|15 years ago|reply
[+] [-] tptacek|15 years ago|reply
[+] [-] AretNCarlsen|15 years ago|reply
http://news.ycombinator.com/item?id=2597256
[+] [-] JoachimSchipper|15 years ago|reply