Is this a good entropy collector and whitening technique? I'm just reviewing a program someone wrote to provide high quality random data using an entropy collector and a hash based whitening technique. I'll try summarize the process:


Collect entropy from sources into separate arrays e.g.


milliseconds between key presses
milliseconds between mouse clicks
mouse movements x + y concatenated together

All the separate numbers are joined into a single array of values (a + b + c).
The array is mixed using a Knuth shuffle using random numbers from the programming language's psuedo random source. I believe a Knuth shuffle works its way through an array in reverse order swapping the current item in the array into a random position in the array.
The items in the mixed array are concatenated together and converted to a single string.
Each 512 bits of the string is iteratively run through SHA2 to give a uniformly distributed 256 bits of output per 512 bits of input. For example if a total of 8192 bits of entropy was collected, the total output would be 4096 bits.


The quality of randomness probably depends on how random the input is, e.g. how randomly the user moved their mouse. It would seem difficult for a person to repeat the same mouse movement path in the same way twice. Let's assume for now the user moved it very randomly and not in a repeatable fashion.

My questions:


Does this give high quality random data compared a PRNG?
What problems are there with this design?
Would "Von Neumann"-whitening work better than hash based?
How could it be improved?
The entropy of a PRNG depends on the quality and amount of "true" random noise used to initialise the PRNG and how much bits the PRNG produces before being re-initialised. A fresh PRNG might be as high quality as your entropy collection above, albeit often a different source such as CPU heat.

The method you cite will not add entropy but will spread the entropy fairly evenly within each 256 bit SHA result (Step 3 can be dropped).

If you want to know the level of actual entropy, just save a lot of results from Step 2 and check with a test suite such as NIST's statistical tests.

The key concern you should focus on is not spreading the entropy (even a non-cryptographic hash like MurmerHash will suffice*) but improving the quality and bitrate of the random noise source.

* If the random source is truly random as it should be, a cryptographic hash isn't needed. If it isn't random, a cryptographic hash reduces inferring the signal in the noise.



EDIT

Regarding Step 1 - If you want stick with keyboard/mouse for random noise input, I suggest you use an approach similar to HotBits timing. 

Only the difference between two or three timings (I forget which is used to cancel clock drift) are used to create a single bit of entropy; a mouse could use pixel travel distance per fixed interval. 

As the timings aren't as random as beta decay, you'll need a NIST test suite or similar to decide on how many bits you need to collect for each SHA-256 hash. Hint: It will be much more than 256 bits.