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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 21 Feb 2013 15:30:16 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Sandy Harris <sandyinchina@...il.com>
Cc:	Stephan Mueller <smueller@...onox.de>,
	Phil Carmody <pc+lkml@...f.org>, linux-crypto@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/