Use USB TRNG as source of randomness for OpenSSL key generation

Question

I have an idquantique TRNG (USB). On my Debian machine, I can easily create a file on my disk coming from that TRNG filled with some random content.

Is it possible to make OpenSSL and GnuPG (for key generation for instance) use the output of that TRNG as source of randomness?

Even better: make these tools making a "mix" of their original randomness source (/dev/random I suppose) and the TRNG source?

I can't fully trust this TRNG (especially because the drivers for it aren't open-sourced).

The purpose behind the last idea is to try to make the randomness better in the best case (where my TRNG is really a true RNG and doesn't have any kind of backdoors) or stay with the quality of /dev/random randomness if the TRNG has some backdoor (repeating patterns, ...) making its output predictable.

Answer 1

Use /dev/[u]random by both feeding it with the entropy of the hardware random number generator and also using it with whatever consumer of random bits you want to use (also OpenSSL will rely on those interfaces). The easy way is simply piping the input to /dev/random, but this will not increase the entropy counter (the driver will have to register as an entropy source to do so).

The kernel will mix entropy from different sources: interrupts because of keyboard and mouse input, network and hard drive timing, ... If you add your hardware random number generator, you will result in a mix of entropy from all of those sources. In the end, any random number with a constant number added up will still remain random, so even if the hardware random number generator is fully predetermined, it will not break the random number generator.

At least, as soon as enough entropy from other sources was added: the only time it might result in guessable random numbers is immediately after the random number pool does not have sufficient entropy from other sources.

I strongly recommend viewing the half-hour lecture The plain simple reality of entropy -- Or how I learned to stop worrying and love urandom held at Chaos Communication Congress 2015, which has a very good explanation of how random number generators mix different sources of entropy. It also explains why you shouldn't care too much of /dev/random and its random bit counter, and use /dev/urandom instead.

Answer 2

Insufficient startup entropy can lead to catastrophic cryptographic failures - read Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices. However, trusting a potentially questionable entropy source is only slight improvement over insufficient entropy - you are only reducing a set of people who could potentially compromise your system. Fortunately, there are open source software-only entropy generators out there - one of them is CPU Time Jitter by Stephan Muller.

However, unless you have a headless system with a SSD, why do you believe that /dev/[u]random is not generating adequate entropy? In most cases, modern Linux kernel is good enough.

Answer 3

As @this.josh and theses responses for a similar question suggested: the command rngd -r /dev/deviceId allows to add a new source (often a hardware device) to feed the the entropy pool.

Since the main difference between /dev/random and /dev/urandom is respectively their blocking or not blocking behavior when the entropy sources are not sufficient, does adding a device to the entropy pool with rngd make /dev/random less secure if the new attached device has backdoors?

In other words does rngd make /dev/random fully trust the new attached device up to point to do not block itself to wait for enough entropy coming from other sources (like network, mouse and keyboard activity) and therefore prevent its output to be a mix of all entropy sources available on the computer? If it's the case it could be a problem when all the others entropy source didn't create enough entropy while my quantum generator did (as it's producing random output all the time) at the exact moment when my program called /dev/random for generating key pairs for example: an attacker knowing the repeating patterns of the quantum generator could easily guess the "random" numbers used at that moment since the output was not a mix of all entropy sources available on the system.