Spinners and compression functions

Since there has been a lot of discussion about spinners derived from various things (idle loops, video retrace, etc.) used as entropy sources, here is yet another idea. Run the spinner output through a PKZip type compression function, and then seed a PRNG with the output from that. This would provide a means of gauging the amount of entropy that has been fed into the PRNG, (count the bytes output from the compression function) which will allow the program to disallow any output from the PRNG until a sufficient amount of entropy has been fed into it. Even if there are correlations in the spinner data, (I know, that is obvious) by the time it has gone through the compression function and the PRNG, it should be cryptographically useful, especially if entropy from multiple sources (keyboard & mouse events, disk access times, network access times, etc.) is used to seed the same PRNG. Jonathan Wienke Political Rant: Re: e$ Signorage
And there I was thinking it was the right for Greenspan to sleep with any unmarried woman on the eve of her wedding...
Actually, that's "prima nocte" (Latin for 'bimbo eruptions" [:)] ) and the principal beneficiary is our beloved President...

JonWienke@aol.com writes:
Since there has been a lot of discussion about spinners derived from various things (idle loops, video retrace, etc.) used as entropy sources, here is yet another idea. Run the spinner output through a PKZip type compression function, and then seed a PRNG with the output from that. This would provide a means of gauging the amount of entropy that has been fed into the PRNG, (count the bytes output from the compression function)
Actually, it doesn't. The entropy present from a reasonable source like keyclick timings is much much lower than the output of pkzip is going to suggest to you. Perry
participants (2)
-
JonWienke@aol.com
-
Perry E. Metzger