On Fri, May 16, 2008 at 12:13:39AM +0200, Jesper Juhl wrote:
quoted text
> My point is that the rate (and timing between) syscalls is depending
> on very many factors; the kernel version (and configuration), the
> software installed, the software currently executing, the state of the
> software currently executing, the number of apps executing, the amount
> of network traffic, the accuracy of the hardware clock, the speed of
> (various) IO sources (network, disk, USB, etc), the speed (and type)
> of the CPU, the speed of memory. And various other things.

It Depends.

For certain workloads, a lot of these issues might just boil out, or
not result in as much entropy as you think.  Think about a certificate
server which doesn't get much traffic, but when it is contacted, it is
expected to create new high security RSA keys and the public key
certificates to go with it.  If the attacker knows the machine type,
distribution OS loaded, etc., it might not be that hard to brute force
guess many of the factors you have listed above.

Basically the question has always been one of the overhead to collect
and boil down any input data (which after all, any user space process
can send arbitrary data into the entropy pool via "cat my_secret_data
quoted text
> /dev/random") which will never hurt and might help.  The tricky bit
is estimating how much "entropy" should be ascribed to data which is
sent into the entropy pool, and this is where you have to be very
careful.

If you screw the entropy credit information then security of
/dev/random will be impacted.  /dev/urandom won't be impacted since it
doesn't care about the entropy estimation.  That's why only root is
allowed to use the ioctl which atomically sends in some "known to be
random" data and the entropy credit ascribed to that data.

	     	     	     	    	     	- Ted
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html