[gnutls-dev] Re: Feature request: not really random session keys

[Florian Weimer]

* Simon Josefsson:

>> Even if we follow the advice in your other message, a busy mail server
>> will deplete the pool at an alarming rate (each TLS-enabled SMTP
>> connection consumes 600 bytes from the kernel pool -- which can only
>> store 4096 bits).  This means that gathering the required true
>> randomness may take a long time.  We'll see if it's still acceptable,
>> or if the randomness is distributed so unfairly that it won't work.
>
> Does /dev/urandom deplete the entropy pool that quickly?

Yes, there is only a single pool, shared by /dev/random and
/dev/urandom.  Each bit you read from the pool reduces the entropy
estimate by one.  There is no way to avoid that, short of artificially
thinning the output (i.e. read 32 bits and turn them into 64 or
something like that).

> It seems to me that /dev/urandom should be a PRNG seeded with, say,
> 256 bytes of good randomness.  It would be quick after that, and not
> require more "real" randomness.  For improved security, it could be
> re-seeded sometimes but that shouldn't be done so often that it
> destroy the /dev/random pool.

This makes a lot of sense, but I could imagine that this is
problematic to get past the kernel developers (because it
intentionally decreases the quality of /dev/urandom output).

> It is probably important to re-seed it, because the /dev/random
> datat used to seed the PRNG may contain little entropy if the
> machine was just re-started,

After a reboot, there is a lot of disk activity, and according to the
current estimates, this creates a lot of entropy.  So it's not a real
issue, unless you need random bits very early in the boot process.  In
that case, you could temporarily switch to a hardware RNG (which is
included in most current systems).

> It may be wise for systems to save the /dev/random pool on shutdown
> and restore it on startup.

Is this really a good idea?  I mean, exposing the pool state like
this?