Jan 20, 2016 at 5:16 AM
Edited Jan 20, 2016 at 5:30 AM
Thank you, sir, for a cogent and rapid response.
I don't see how you deduced from the documentation that the entropy is gathered from the windows of other applications. Maybe it should be written "mouse movements on the displayed VeraCrypt window" . . .
This: "The mouse is only one part of creating random values"
plus this: "The VeraCrypt random number generator . . . creates a pool of random values . . . which . . . is filled with data from the following sources: . . . /dev/random . . ."
plus the fact that the linux kernel usually uses mouse and keyboard activity, amoung other things, to generate entropy to send to /dev/random
seemed to imply that.
Did you test this? For example, before creating a volume or before changing the password, you are presented with a dialog that invites you to move your mouse and this is where the mouse entropy is gathered.
Yes. Unless I'm misunderstanding you, that is exactly what I was referring to when I wrote:
"But when I tested this by opening up another program (I tested with gedit, lxterminal, and transmission) and moving it down so I could still see the Veracrypt window despite the other window having focus, neither moving the mouse-pointer, nor typing in
the other program had any effect on the speed with which new characters appeared in the "Random Pool:" field (set to show) in the "Volume Format" dialogue of the "Veracrypt Volume Creation Wizard". Regardless of what window has
focus, only moving the pointer over some visible portion of the Veracrypt window seems to have any effect."
In retrospect, I should have said "any OBVIOUS effect".
The dialog that is presented to you when you move your mouse only captures mouse movements to increase the internal pool entropy and it doesn't call /dev/random and /dev/urandom.
So, at this point, something that fed /dev/random faster, like a hardware RNG, even a fast one, would have no effect?
Or is it that when the pointer is over the VC window, and VC itself is generating entropy from that movement directly, the method used is more efficient and a larger amount of entropy is generated per unit time, whereas with the pointer over some other window,
the kernel only uses the least significant digits of numbers describing position to generate entropy to send to /dev/random from which some of it then trickles into VC at a much slower rate?
If the latter is the case, would it be probable that a sufficiently powerful hardware RNG, pumping entropy into /dev/random at a much higher rate than the kernel can, could eliminate the need for pointer movement?
I do NOT mean "Would it be possible to rewrite VC to make it work this way?" -
I mean "Would this happen automatically if I did something (like install a hardware RNG) that fed /dev/random a lot faster than the kernel normally feeds it?".
Or would I have to write something extra, like, for example, a bash script to jiggle the mouse around with an endless loop with
xte 'mousermove x y'
with x an y derived from /dev/random if I wanted a behaviour like this? (Well, somewhat like it, anyway. I still wouldn't be able to do other stuff - unless maybe I started a second x session in another tty)
And if EITHER approach is likely to work, is it possible to make an educated guess quantifying approximately how powerful a hardware RNG would need to be to generate entropy as fast as deliberately random mouse movement in the VC window? There are some fairly
inexpensive hardware RNGs out there.
Thanks for the project, and thanks for your thoughts.