[The From: is a bitbucket, to deflect the hordes of broken
autoresponders. Use the address in the signature to reach me.]
> The original email pointed out that disk seek times may not be quite
> as random as previously thought, especially with compact flash and
> similar mediums.
According to the documentation, on NetBSD, at least, the accumulation
code backing /dev/random requires that...well, let me quote rnd(4):
When a hardware event occurs (such as completion of a hard drive transfer
or an interrupt from a network device) a timestamp is generated. This
timestamp is compared to the previous timestamp recorded for the device,
and the first, second, and third order differentials are calculated.
If any of these differentials is zero, no entropy is assumed to have been
gathered. If all are non-zero, one bit is assumed. ...
(I haven't checked the code to see whether it actually matches the doc,
but I have no reason to think it doesn't.)
So I guess I don't see what the problem is. Mixing
attacker-predictable data into the pool does not improve matters, but
it doesn't hurt matters either (unless the mixing is done stupidly and
is really replacement, which does not appear to be so).
Are other OSes stupider about their rnd(4) (or moral equivalent)?
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@xxxxxxxxxxxxxxxxxxxxxx
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
