On Fri, 2008-05-16 at 00:55 +0300, Adrian Bunk wrote:
There are two issues that people need to separate here:
- sampling noise
- estimating entropy in that noise
It certainly makes sense to sample network timing noise. It often does
not make sense to assume that there's any entropy in those timing
samples. For instance:
- our clock resolution may be low enough that an attacker can guess our
samples (ie it's simply HZ, very common in embedded land)
- the bus involved (ISA, peripheral bus, even slow PCI) may have the
same issue
- it may be heavily correlated with some other measurement (ie network
vs disk samples on file servers)
We currently assume that IRQF_SAMPLE_RANDOM means 'this is a completely
trusted unobservable entropy source' which is obviously wrong for
network devices but is right for some other classes of device.
I'd personally prefer to add a new interface, eg
add_network_randomness(), that internalized the wisdom of what to do
with network samples. Similarly, the various 'input'-like devices that
use SAMPLE_RANDOM should be switched to go through the 'input'
interface.
--
Mathematics is the supreme nostalgia of our time.
--
