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
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
