Does iterative hashing of mouse/keyboard input improve its properties as an entropy source?

Question

In the questions, Are mouse movement coordinates useful as a seed for a RNG? and Is this a good entropy collector and whitening technique? the posters each talk about collecting mouse and keyboard input as a source of entropy. The replies make the good point about this being dangerous and requiring a large sample to ensure sufficient entropy for cryptographic purposes.

I am wondering if the quality of these inputs as entropy sources would be improved given the following scheme and, if so, by how much?

Imagine a system where X is some input from the user (e.g. mouse coordinate pair or key code combined with current timestamp) and H is some latest-generation hashing function and e is our current entropy pool state after each iteration. After the first input is collected we have:

e = H(X1)

This has low entropy. We collect another sample from the user and this time combine with the previous entropy and and hash it:

e = H( X2 + e )

or:

e = H( X2 + H(X1) )

Then we keep doing the same thing for each new value collected, combining it with the previous entropy and hashing them together:

e = H( Xn + e )

or:

e = H( Xn + H(Xn-1 + H(Xn-2 + H(Xn-3 + ...))) )

Does hashing iteratively like this in any way change the rate of improvement of the quality of the entropy produced, or is it about the same as collecting all of the samples and hashing them once like this:

e = H( X1 + X2 + X3 ... Xn )

Update

This answer to What happens to entropy after hashing? also has a good analysis that I think applies here:

If we have a Hash function SHA which doesn't have any collisions, then it has no effect on entropy; that is, H(X) = H(SHA(X));

Answer 1

The biggest problem with capturing mouse & keyboard input is that the number of likely things a user does within a small timeframe is limited.

Imagine that you hash 3 alphanumeric characters of userinput H(X1 + X2 + X3) (assuming + means concatenation and H is a cryptographic hashing function). The number of possibilities from 000 to ZZZ would be about 62^3. Now if instead you would use H(X3 + H(X2 + H(X1))) the number of possibilities would still be 62^3. You could even use something like pbkdf2 with a ridiculous number of iterations without changing the number of possible outputs.

Answer 2

One should always apply a slow, one-way function to user input. While it has no effect on the number of possible outputs, applying such a function (like an iterated hash) does help defend against attacks.

Imagine you ask the user to click on random locations. Upon each click, you record the location of the cursor. After the third click, you have three points in the space of 1920x1080 (on a full HD screen, as an example). This is your upper bound on the randomness of it, as Daan Bakker already described.

Now some novel research is released which describes how users select such locations. It might turn out that few people click the same place twice after each other. This allows an attacker to predict the next two points with a higher probability, and such an attacker can start cracking any keys which were based on this entropy source.

If a slow one-way function such as Scrypt or Argon2 (or, in a more basic form, any iterative hash) had been applied to the user input, an attacker can only do guesses as fast as this function allows. For example, I was looking through some source code which generates private keys, and it bases the keys solely on input from mouse movements. The RSA key generation process is still slow so that is lucky for the user, but the derived keys might as well have been something like symmetric keys for disk encryption. Those are extremely fast to generate, and could be guessed at very high speeds if no slow function is applied to the randomness.