[Help-gnutls] Alternate random device for certtool

Nikos Mavrogiannopoulos nmav at gnutls.org
Fri Dec 5 21:06:38 CET 2008


Werner Koch wrote:

>> I don't understand. The issue for certtool that was reported was that it
>> was blocking in /dev/random and taking a lot of time to produce any
>> output. This was the reason I've put QUICK_RANDOM there.
> Right, it is blocking because it needs to generate random numbers and do
> do this we need to gather entropy from physical sources.  If the
> bandwidth of these sources is that small it just takes a long time.  If
> the box is idle it may even not finish at all.  Recall that a computer
> is a deterministic machine and that it is hard to extract unpredictable
> events from a deterministic machines (actually impossible, but
> fortunately a general purpose computer is not completely deterministic.)

There are many parts in a typical PC that can feed a prng with
non-deterministic data. Typical examples are the network card and sound
card (mic etc), hard disks, memory accesses, interrupts, thermal sensors
etc. Those provide lots of information that can feed a prng even on
unattended system.

There are two problems with the linux prng:
1. It needs to block when it thinks it does not have enough randomness
2. It does not use all available random data sources because its state
could be compromised by a malicious or broken source.

Fortuna [0] is a suitable PRNG replacement, because it has none of these
issues. It can work even with some sources being malicious and will use
a block cipher to produce large series of data without compromising or
its state.

[0]. http://en.wikipedia.org/wiki/Fortuna_(PRNG)

> Ask the user to work on the box to give it a chnace to collect entroy.
> For example "find /usr -type f | xargs cat >/dev/null" gets the disk to
> work and thus floods the box with interrupts.

The problem is that programs should be able to run both interactive and
not.

Moreover the blocking interface makes it's easy to prevent someone from
creating a key... Just cat /dev/random, or open many tcp connections to
a linux host.

>> [0]. Also being blocking does not protect from being a bad algorithm. As
>> far as I know there are known issues to the blocking linux rng (were
>> discussed some years ago in gnutls-dev) and they still cannot gather any
>> entropy from network devices because its state can be compromised!
> And thus your solution is to give up on it and use a a deterministc
> source like /dev/urandom?  If /dev/random blocks, /dev/urandom will only
> return a sequence of bytes which is predictable if you know the initial
> state of the RNG.

/dev/urandom is not deterministic it just has worse PR.
/dev/random is the SAME as /dev/urandom with the exception that it
blocks when it THINKS randomness gathered is not enough. If it thinks
wrong (like when I control one source of randomness) it exactly the same
as /dev/urandom.


regards,
Nikos



More information about the Gcrypt-devel mailing list