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

[Simon Josefsson]

Florian Weimer <fw at deneb.enyo.de> writes:

> * 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).

Ouch.  This seem sub-optimal to me.

>> 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).

I don't see how it decreases the quality.  /dev/urandom is documented
to potentially be vulnerable to a cryptographic attack.  Pick a PRNG
and you fulfil the documented security problem, as far as I can see.

Do you know if anyone has done any work on /dev/*random in the kernel
lately?  Perhaps we could talk to them.

>> 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.

If it is using delays from the disk as entropy sources, I think it may
not be impossible to predict them, or at least predict a set of
possible delays.  Especially if you are booting from flash disks or
similar.

> 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).

That's probably a good idea anyway.

>> 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?

Perhaps not on desktops, but perhaps on embedded systems.

Thanks!