[gnutls-dev] Re: Feature request: not really random session keys
jas at extundo.com
Mon Jan 30 18:02:45 CET 2006
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
> 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
Perhaps not on desktops, but perhaps on embedded systems.
More information about the Gnutls-devel