This project has moved and is read-only. For the latest updates, please go here.

TRNG for Random Pool

Topics: Feature Requests
May 1, 2015 at 1:11 AM
When formatting a volume, rather than moving the mouse, I would like to see the option to use a USB TRNG for seeding the Random Pool.
May 6, 2015 at 11:25 AM
Edited May 6, 2015 at 11:25 AM
There was a similar request here:

VeraCrypt doesn't rely on mouse movements only but it also uses various system entropy sources.

I'm open to add support for external entropy sources as long as there is a generic interface for accessing them and that doesn't depend on a specific manufacturer. Do you know if such TRNG support PKCS11 interface or CAPI interface?

That being said, I'm open to the possibility of a manufacturer sponsoring the development of support of its TRNG hardware in VeraCrypt.
May 6, 2015 at 2:46 PM
TRNGs may be subject to future revelations of security weaknesses, unlike mouse movements. Thus any future option to use TRNGs should use them only as a supplemental source of randomness - never as any kind of complete replacement for mouse movements.
May 7, 2015 at 7:30 PM
I believe that on a Linux machine one may fairly easily fill the random pool with a USB TRNG, but not so on Windows. I have posted a question on the TrueRNG forum regarding PKCS#11 or CAPI interface support for Windows 7, and will post the information here if I get encouraging feedback. Thanks.
Aug 7, 2016 at 7:26 AM
Essentially, you can do this with the text interface now. I don't know about Windows
but for a 'nix of any sort, the right approach is to use the TRNG to feed /dev/random,
so the output WILL be mixed with other sources automatically. The quality of
randomness is potentially higher, and at worst, no lower, assuming I understand
it correctly. You can create a file in a ramdisk and fill it with as much randomness
as you want. And you can use the file for the randomness source.
I've been tinkering with this. It seems to me the simplest universal
interface for the GUI is to use the same thing the CLI uses and simply to cat
a file of the user's choice or to take in the output of /dev/random
as a stream as long as the user wants to wait. VC itself could set up a ram disk, let
a file in it grow until the user clicked "enough already", and from there, no
new underlying code of significance would be needed. I may be all wet about
that because I haven't actually tried an ever-growing-file approach. But if you
are content to specifiy how much random data you want ahead of time, this is
definitely do-able and not that difficult. If you have a TRNG that can't feed
/dev/random securely one has to wonder what its designers had in mind, assuming
they have minds, and who they work for.

One note of warning, I believe I've read there is at least one OS (one of the
BSDs maybe?) that has a faux /dev/random that is just a link to /dev/urandom. The
dev's attitude was that dumb users don't need access to /dev/random anyway &
he didn't want bug reports about slow output of /dev/random. Well, gee, what an
Equus Assinus.