[systemd-devel] Delaying (SSH) key generation until the urandom pool is initialized

[Florian Weimer]

On 05/02/2014 01:05 PM, Lennart Poettering wrote:

>> No, /dev/random can (and will) block long after booting.
>
> But that's what you want in this case, no? You want this to block after
> booting if there never has been enough entropy in the pool, right?

What I want is no blocking at all.  If the pool is initialized, this is 
safe unless there is a crippling bug in the kernel random driver (or 
complete break of SHA-1, significantly worse than what's known for, say 
MD4).  If the pool is not initialized, it is practically possible to 
enumerate all possible pool states, and thus predict the data that comes 
out of /dev/urandom.

So I grudgingly accept that some things have to block until /dev/urandom 
is initialized.

> Is there any kernel API currently available to at least query if the
> pool is properly initialized?

No, there isn't.  I proposed a patch for a new variable in /proc, and 
the question came up whether this is what userspace needs.

There is now a separate discussion about injecting a few bits of entropy 
that in the virt case (where entropy is generally scarce initially), the 
pool is always initialized.

> So you have multiple options:
>
> a) fix the kernel to make /dev/urandom block until enough initial
>     entropy has been gathered. Would fix the roblem, but probably slow
>     down systemd. In systemd the hash functions used in hash tables are
>     keyed off /dev/urandom, in order to make collision attacks
>     difficult. This only requires low-quality entropy, as we rehash with
>     a new key anyway should the hashtable reach its initial size
>     limit. Hence blocking reading of /dev/urandom until the pool is
>     initialized will slow down systemd since would have to block without
>     actually needing any quality entropy...

If systemd is blocked on /dev/unrandom at this stage, will anything else 
happen on the system that generates more entropy?

> b) fix the kernel to make the behaviour explained in a) something
>     optional, maybe something that is enabled on /dev/random when
>     O_DIRECT or so is passed during opening. i.e. if that flag is
>     specifiied that /dev/random will behave like classic /dev/random
>     until the initial pool is filled up, and like /dev/urandom
>     afterwards.

Or perhaps a separate device node.

> I am very conservative howver to simply delay the boot until the pool is
> initialized.

I want this for specific services only.  For things like hash tables, 
it's possible to reseed once more randomness becomes available, but 
that's not true for long-term key generation.

-- 
Florian Weimer / Red Hat Product Security Team