> On 30 May 1999, Florian Weimer wrote:
>
> > After subtracting the timer interrupts, we get an average of over
> > nine bits added on each /dev/psaux interrupt to the /dev/random pool.
> > I don't think that there is that much entropy involved to justify this
> > high value.
>
> How many bits would you propose? Remember you've got several sources of
> randomness here:
> 1) time between mouse events (in processor cycles, usually)
> 2) x delta
> 3) y delta
> 4) button status
I'm terribly sorry but I missed sources 2 to 4 (and the parameter to
add_timer_randomness). In addition, I have grossly underestimated the
cycle clock speed of today's machines. :(((
> I suspect during your test you were tossing the mouse around quite
> randomly, leading to a greater amount of entropy added to the pot than
> if you observed more 'natural' conditions with smaller mouse
> movements.
Yes, I did. But this shouldn't influence the results, because the data
parameter in add_timer_randomness is not used for entropy estimation.
I would certainly like to end the thread after this, but I've got one
further question: The implementation of /dev/random assumes that the
output of the SHA-1 hash function is random for random (or almost random)
input. Neither the people on sci.crypt nor I know of any analysis
of SHA-1 in this direction (which doesn't prove anything of course).
Are there any particular reasons why SHA-1 was chosen to supersede MD5?
(It might indeed become practical to find collisions for MD5 soon,
but this doesn't mean that MD5 is not suitable for applications like
/dev/random.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/