[149294] in cryptography@c2.net mail archive
Re: [Cryptography] cheap sources of entropy
daemon@ATHENA.MIT.EDU (James A. Donald)
Sun Feb 2 01:38:47 2014
X-Original-To: cryptography@metzdowd.com
Date: Sun, 02 Feb 2014 16:25:32 +1000
From: "James A. Donald" <Jamesd@echeque.com>
To: Jerry Leichter <leichter@lrw.com>
In-Reply-To: <EE35F422-34A6-45AD-8915-A25F1B8FDA91@lrw.com>
Cc: cryptography@metzdowd.com, Bill Stewart <bill.stewart@pobox.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 2014-02-02 14:27, Jerry Leichter wrote:
>
> No, Bill Stewart is right. There are multiple layers of software with all kinds of buffering, queuing, operations that are kicked off by clocks at fairly long intervals (way longer than the timing variations seen in disk responses), in between. It's highly unlikely that any low-level variation in disk response times will be visible by the time you reach the guest OS.
>
> There *will* be variations, but exactly what produces them, what they are correlated with, how predictable they are, would be extremely difficult to answer. If you go back to the original paper on disk drive timing variations, you'll see careful work to figure out exactly what kinds of variations disk drive timings will produce, and then actual measurements to show that the results really match the physical models. No one, as far as I know, has done any work like that in a virtual environment - and frankly I doubt anyone could. The pieces are just too complicated.
The only efficient way to organize the system is for process switches to
be triggered by the arrival of data. Fail to do that, you wind up
reading one sector per platter rotation. If you want to read sectors as
the platter rotates, you have to do process switch on disk event, not
timer event.
If you do that, switch process on disk event, rather than the timer
event, process switches will occur at times dictated by disk drive
turbulence when a process is reading data.
Disk drive turbulence is true random and unpredictable to an adversary,
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
