[Cryptography] cheap sources of entropy

[James A. Donald]

On 2014-02-03 03:27, Dennis E. Hamilton wrote:
>     -----Original Message 1 -----
> From: James A. Donald
> Sent: Saturday, February 1, 2014 22:26
> Subject: Re: [Cryptography] cheap sources of entropy
>
> [ ... ]
> 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.
> [ ... ]
>
>     -----Original Message 2-----
> From: James A. Donald
> Sent: Saturday, February 1, 2014 22:31
>
> [ ... ]
> The hypervisor is going to switch a process out when it wants data that
> is not yet available, rather than switching it on a clock.
>
> If it switches a process in when data is available, rather than
> switching on a clock, turbulence is going to show up, even if that disk
> is on a network on the other side of the data center.
> [ ... ]
>
>
>     -----Reply-----
> I am baffled by these assertions.  They strike me as very brittle conditions that are contrary to how input-output latency is dealt with in production systems.  Perhaps I don't understand the context in which these assumptions apply.
>
> The red flag for me is "the only efficient way."  The way latency is minimized in modern general-purpose systems is to not make success dependent on the behavior of a single requester and to serve input-output requests more indirectly.  This kind of throughput optimization can, of course, extend the elapsed running time of individual processes on a busy system while working to avoid overall slow-down because of input-output latency issues.
randomness is not "brittle", it is pretty robust and hard to get rid of.

If you have a complex system that contains a true random component, the 
entire system will usually to have true random behavior, with the 
complexity adding pseudo randomness to the true randomness.

If one level of the system is cpu bound and switching on the clock, not 
on IO, then yes, that will suppress turbulence based randomness, but:

if you are cpu bound, then you will still get timing randomness, not 
from turbulence, but because of the many things that all the other 
processes are doing and clock skew between the various levels of the system.