When is the blocking RNG called?

[Werner Koch]

On Thu, 23 Nov 2000, Enzo Michelangeli wrote:

> Does "high quality" (i.e., blocking in low-entropy conditions) random number
> generation occur only for keypair generation, or also in other circumstances

Yes.

> (e.g., when session keys are generated, DSS signatures computed and session
> keys wrapped in ElGamal packets)? When using rndlinux, this is equivalent to

No, this does only use /dev/urandom and the fast poll.  We always mix
in some stuff we can gather quite fast: pid, time, resource stats.
For the DSS k parameter this is IMO sufficient because the main
concern here is that we will never ever use this k again and due to
the mixed in pid and time this should be accomplished.  

For most things we use the PRNG build on hashing the pool and
reseeded it with calls to fast_random_poll; otherwise we would
really run into problems on most machines due to the low entropy
available.  Using /dev/urandom does not give much advantage here
because most times it will fall back to the PRNG behaviour anyway.
One way to improve things could be by reading /dev/randoms internal
buffer without draining it - I am not sure whether there is an API
for it and if there is such a API it must be accessible by a normal
user (and not only root) which in turn means that the kernel has to
make sure that the internal state of its pool does not leak out.

Fo key generation we make sure to get better entropy by requiring 2
things: The pool must have been filled up to 50% with /dev/random
stuff _and_ we put at least so much /dev/random bytes into the pool
as we are going to retrieve for key generation.  This is somewhat
optimized by keeping a pool_balance counter which is inncremented
for ever new byte from /dev/random and decremented for every byte of
random we exract from the pool (either quality 1 or 2).

There is also a random_seed file which we use to initially fill up
our pool.  In most cases this is done by reading stuff
from/dev/urandom. The advantage of this seed file is that we don't
extract stuff from /dev/urandom each time we fire up gpg.  These 600
bytes of the pool are quite a lot and because /dev/urandom and
/dev/random do share one pool it would be bad to read from
/dev/urandom when there is no real need for it.

I'd really like to have some cheap hardware RNG to improve this a
bit. I am currently thinking of building such a thing combined with
the Dallas 2480 driver chip which is used to access iButtons and it
should fit well into a serial or USB adapter.


  Werner