This project has moved. For the latest updates, please go here.

mouse movenemt & entropy sources in crypt creation

Topics: Technical Issues
Jan 19, 2016 at 8:15 PM
Edited Jan 19, 2016 at 8:19 PM
I read this at the sourceforge* veracrypt forum:

"The mouse is only one part of creating random values. You can read about the details at the link below.

https://veracrypt.codeplex.com/wikipage?title=Random%20Number%20Generator
"
That and the page linked to seem to suggest that, in the linux version at least, I can go and do other things in other windows and generate the needed entropy with other work. 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.

So, is moving the pointer in fact, the only source of entropy? Or does anything feeding /dev/random work? And if the latter, why isn't that reflected in the rate of change in the Random Pool field? If I installed a hardware RNG, would it obviate the need for mouse movement? If so, would that be reflected in the rate of character generation in the Random Pool field?

A second and related question: That link says VC uses entropy from "both /dev/random and /dev/urandom". Is there a way to force it to use only /dev/random?

. . . . . . . . . .
* As an aside, before finding this forum, I tried to register there, couldn't, searched to figure out why, and encountered this:
http://www.infoworld.com/article/2931753/open-source-software/sourceforge-the-end-cant-come-too-soon.html
No more sourceforge for me!
Coordinator
Jan 19, 2016 at 10:39 PM
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" because this is where mouse movement are captured before every sensitive operations.
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.

The first paragraph clearly states that on Linux, the random pool is filled also with /dev/random and /dev/urandom. This is done when the sensitive material is to be generated. 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. That's why entropy doesn't increase when you are doing other things on your machine.

For now, we always use both /dev/random and /dev/urandom. There are two exceptions to this:
  • when using multi-pass wipe, only the last wipe pass uses both /dev/random and /dev/urandom to get entropy: the previous ones use only /dev/urandom
  • when generating the volume ID of a FAT volume, only /dev/urandom is called.
These exceptions are needed to avoid spending too much time since /dev/random can be slow because of entropy starvation on the system.

Anyway, I understand the need for using only /dev/random. I may add an option to enable this alongside another option to force VeraCrypt for wait for full entropy to be available in /dev/random: this will encrease quality of random pool but it can make operations much slower especially on machines affected by entropy starvation.

For those interested, here is the relevant code: https://veracrypt.codeplex.com/SourceControl/latest#src/Core/RandomNumberGenerator.cpp

Concerning Sourceforge controversy, I have already given my opinion here: https://veracrypt.codeplex.com/discussions/642232#post1436934
Jan 20, 2016 at 5:16 AM
Edited Jan 20, 2016 at 5:30 AM
Thank you, sir, for a cogent and rapid response.
idrassi wrote:
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.

idrassi wrote:
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".

idrassi wrote:
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.
Apr 23, 2016 at 9:35 PM
For anyone else interested in this, I've come to realize that the
answer is to use the command line interface instead of the gui. Then
you can use the content of a file instead of mouse movement. And,
of course, there are a bazillion ways to put any arbitrary amount
of random stuff in a file. And you can use /dev/random, or the output
of a hardware RNG directly if you want to. It is very flexible and
you can script it. You can generate the file in a RAM-drive and turn off
swap or paging. CAUTION: If you really NEED security, and aren't just
playing with it like I am, you could screw up rather badly if you
try to follow the above without completely understanding it. If you
aren't sure you follow all of it, stick with the gui until you do.
The gui is fine for most practical purposes.