[Cryptography] cheap sources of entropy

[Bill Stewart]

At 02:33 PM 1/31/2014, James A. Donald wrote:
>If you are on a VM, probably have a disk drive with turbulence.

Definitely not.  If you're on a VM, you have 0..n virtual disk 
drives, which the hypervisor simulates from a datastore pool and 
maybe some cache.  You don't get any access to the real device, even 
though the hardware drivers look like they're talking to a disk.

>If you do not have a disk drive with turbulence, probably have your 
>own microphone and video input.

Most shared servers that are running virtual machines images don't 
have physical sound cards, and they may have a few shareable USB 
ports but they typically won't have video cameras plugged into 
them.  There might be a sound card built into the chipset, but you 
typically don't have access to it.  For instance, when I look at the 
Virtual Machine Settings for my VMware box at work, it doesn't even 
have the option for attaching a virtual sound card to the VM.

The exception is cases like VMware Player running on your desktop, 
which probably can access most of your actual hardware, or virtual 
machines running on mobile phones(because yeah, that's a thing these 
days), which may have lots of toys handy, but your typical web server 
running on an Amazon cloud instance isn't going to have any of those 
things available.  You're probably also not going to be able to log 
in to the VM's console and wave a mouse around (and doing an X 
Windows session isn't going to happen until after ssh has already 
been initialized.)

>So, get microphone input and clock skew and network events and disk 
>drive turbulence and hash them all together.  One of them is bound 
>to work.  The class of machines on which one of these fails is 
>different from the class of machines on which another of them fails.

Even network events are pretty sparse on a vSwitch, compared to the 
constant blather that real ethernet ports typically see.  There isn't 
all that spanning tree noise, maybe you get some ARP broadcasts, but 
only from your other VMs on the same server cluster, vanilla users 
don't have the permissions to set the vSwitch port to promiscuous receive.

"If you don't like the noise, go make some of your own", i.e. you'll 
have to start sending out traffic to known or unknown places and 
using low-level timing of the responses (and even that's not going to 
be as independent as you'd like, since it'll be correlated with the 
granularity of when the hypervisor gives you some CPU cycles), and of 
course all of that traffic is theoretically independently observable, 
not that that's too credible a threat.