Eric wrote:
> Adam wrote:
> > There is for example code in PGP which looks at inter key press
> > timings, and constructs 1st and 2nd order differentials to try to
> > avoid stuck keys, people pressing the same key repeatedly etc.
>
> There's also the code in the linux /dev/random implementation, which
> keeps a running estimate of the entropy that's beeing added
> to the random pool, a byte at a time.
Yes.
/dev/random does entropy counting in bits.
I've got a small test program which uses the /dev/random ioctl
interface specified in /usr/include/linux/random.h, and you can do fun
things with it like zero the pool out, or zero the pool counter (as
root), and watch the entropy count grow as you press keys and swirl
the mouse.
I think I found a sort of bug in that if you hold a key down, the
entropy count increases rapidly, and yet the only entropy it will be
getting in this circumstance is the clock jitter.
You can see the effect if you do:
% od -x < /dev/random
and hold down for example the control key, or any other key. You get
a continuous stream of output while you hold the key down. This
applies whether or not you are using X.
It's a bug in the sense of over-estimation of entropy. I haven't
looked what the clock jitter looks like, but it may be pretty
quantized and yet still pass the timer differential tests of in
/usr/src/linux/drivers/char/random.c. The timer is pretty high
resolution.
I think it would be more secure to examine the scan code and discount
the entropy estimate for the sample if it came from the same key.
It outputs bytes at pretty high rates if you move the mouse also.
Adam
