Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput

["Theodore Ts'o" <tytso@mit.edu>]

On Thu, Feb 21, 2013 at 12:46:45PM -0500, Sandy Harris wrote:
> 
> Also, in some designs it is possible to get very close to calculating
> entropy. The Turbid generator, for example, uses physical measurements
> of sound card properties plus arguments from standard circuit physics to
> prove a lower bound on the Johnson noise that must exist in the circuit.
> From that plus some quite moderate assumptions about properties of
> the hash, you get a provable lower bound on output entropy.

That's assuming you're talking to a real physical sound card, however.
Suppose you have a set up where the user is running one or more VM's
on their desktop, and the VM (possibly with some assist from
PulseAudio) is multiplexing the host sound card and doing upmixing
and/or downmixing as part of its multiplexing magic?

Would the Turbid generator be able to detect this situation, and would
its entropy estimates be correct?  Even if they are correct, the fact
that another VM might be getting the same stream of inputs,
unbeknownst to the Turbid generator, might mean that an adversary
might have access to the "entropy" being generated by the PulseAudio
stream....

(And yes, there is the same potential issue with the current
/dev/random sampling what it thinks is hardware noise generation from
network and hdd interrupts; the point is that entropy collection in
the VM is *hard* and extremely error-prone.  In the end you're
probably better off using paravirtualization for /dev/random and trust
the Host OS to give you good randomness.  After all, if you don't
trust the Host OS, you're fundamentally screwed anyway....)

							- Ted