True RNG and GnuPG / libgcrypt

[Matthias-Christian Ott]

On 09/26/13 04:45, NIIBE Yutaka wrote:
> For me, it will be simple and solid if we can use the output of an RNG
> device directly, for key generation operation of GnuPG, given the
> condition where such an RNG device has best quality.
> 
> I mean, it would be good to have an interface which allows using RNG
> device directly (even if /dev/random is available).

That is a bad idea. How much “true randomness” per bit does NeuG
generate? If this is less than 1.0, you could weaken security. For
example with (non-deterministic) DSA you could leak parts of the private
key, if the attacker can predict partially predict the output of the
random number generator with a model of the device. So you can't simply
read 128 bit of output from the random number generator, use it directly
as the key and assume that your key provides “128 bit security”. You
probably have to read a lot more and then compress the data with a hash
function.

>From what I've read about measuring the quality of randomness sources
you have to test raw output of the random number generator (according to
the website NeuG's output is biased and needs post-processing) and the
output random number generator should significantly differ after each
restart. AIS 31 is often cited in the context. Unfortunately I don't
understand statistics involved, so you have to do the research yourself.
For example with ring oscillator based random number generators which
were believed to be simple and “secure” (the VIA Padlock RNG is based on
ring oscillators [1]), there have been publications recently that
question to what extent the output of those generators is “truly random”
and to what extent it is deterministic.

I guess what I want to say is the following: Measuring the quality of
random number generators is not as easy as running the Diehard or NIST
tests on the output and assuming that the output is “truly random” just
because it passes the tests. If you want to use the output of the random
number generator directly you should somehow “know” how much “true
randomness” per bit of output it yields. Feeding the output of the
random number generator into /dev/random has the advantage that it gets
mixed with other sources of randomness and that there is a single
implementation that can be peer-reviewed.

Probably there are better attacks than predicting the output of NeuG and
xkcd 538 right, so this discussion doesn't matter in practice.

Regards,
Matthias-Christian

[1]
http://www.via.com.tw/en/downloads/whitepapers/initiatives/padlock/evaluation_padlock_rng.pdf