[clug] entropy

[Martijn van Oosterhout]

On Sat, Aug 30, 2003 at 11:33:12AM +1000, Nemo -earth native- wrote:
> On Sat, Aug 30, 2003 at 11:10:01AM +1000, Martijn van Oosterhout did utter:
> > cache. One bit of entropy per network packet would be enough for most
> > things.
> 
> "most" isn't good enough for hte paranoid who want /dev/random to be
> truly crypto usable, and there is /dev/urandom for anythign that will
> suffice with pseudorandom randomness on those occasions when entropy is
> empty. 

Well, I've just looked at the code and no wonder people are worried. What is
calculated is the first, second and third order deltas between timings. It
then bases its entropy estimate on that. Also, on machines that are not i386
or ia64, the counter used is jiffies which has no useful resolution for this
kind of thing.

If you work this way, then you assume that the timing between two keystrokes
is so random that it could add 12 bits of entropy to the pool each time. The
lower 12 bits of the CPU cycle counter will wrap several thousand times per
second even on low end machines so even the calculated entropy estimate is
random. For things like disk seek timings it's still useful.

But to me the assumption that since it's been twice as long since the last
event there is an extra bit of entropy there is what is flawed.

From looking at the code though, non-Intel machines must have a hell of a
time extracting entropy. A busy disk sub-system will generate so many
interrupts that the entropy estimate will be consistantly zero (jiffies is
only milliseconds or more on most systems).

> > Basically, you need to find out what *does* count as entropy if network
> > traffic doesn't. If hard disks interrupts count, maybe a find / from a
> > cronjob every couple of hours. That's the only easily controllable thing I
> > can think of.
> 
> I know I've heard of patches in the past that let you give greater
> control over what does/doesn't contribute to entropy...

Since IMHO it's the overestimate of entropy that's the problem, perhaps
that's what needs to be fixed. On a 200MHz machine, if you receive around 60
packets a second that are evenly spaced (1ppm variation) the system will add
around 2-3 bits of entropy for each one, more for higher clock speeds, less
for higher traffic.
.
Whether that's too much is a matter for debate. IMHO, it's fine because from
the time it hits your network card to when the CPU actually sees the
interrupt involves 3 different system busses running at different speeds,
what instruction it was executing at the time and the state of the cache.

For non-Intel machines it's definitly a bad idea.

> This IS a kernel patch however, but would appear to give you the control
> required to feed entropy from the network :)

For Intel machines with a TSC connected to a low usage network, it should be
fine.

-- 
Martijn van Oosterhout   <kleptog at svana.org>   http://svana.org/kleptog/
> "All that is needed for the forces of evil to triumph is for enough good
> men to do nothing." - Edmond Burke
> "The penalty good people pay for not being interested in politics is to be
> governed by people worse than themselves." - Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux/attachments/20030830/d3f12606/attachment.bin