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

[Simon Josefsson]

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

> * Simon Josefsson:
>
>> Florian Weimer <fw at deneb.enyo.de> writes:
>>
>>> I tracked this down to the generation of the RSA_EXPORT key.  In this
>>> case, bits from /dev/random are used, even though the generated key is
>>> horribly insecure anyway.
>>>
>>> Wouldn't it make sense to use only STRONG_RANDOM in this case, and not
>>> VERY_STRONG_RANDOM?
>>
>> Perhaps.  But doesn't this happen for non-RSA_EXPORT keys too?  We
>> wouldn't want to make that change there.
>
> I think you'd need to pass an additional flag, yes.  It's certainly
> not a two-line change, and I can understand if you don't want to make
> it for such a silly feature.

I dunno.  Let's see what options we have.  There isn't a patch to
consider at this point anyway.

>> It seems better to fix Exim here.
>
> 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?  That seem
like bad design.

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.  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, or if it is an embedded
system with few entropy sources.  It may be wise for systems to save
the /dev/random pool on shutdown and restore it on startup.

Thanks.