[gnutls-dev] Re: Feature request: not really random session keys
jas at extundo.com
Mon Jan 30 17:27:42 CET 2006
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
>> 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.
More information about the Gnutls-devel