Messages in this thread | | | Subject | Re: /dev/random and /dev/psaux: too much entropy assumed? | From | Florian Weimer <> | Date | 01 Jun 1999 20:19:15 +0200 |
| |
"C. Scott Ananian" <cananian@lesser-magoo.lcs.mit.edu> writes:
> 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/
| |