Re: FYI/RFC: early-rng-init-tools

[Thorsten Glaser <tg@debian.org>]

Ben Hutchings dixit:

>>     ‣ writes between 32 and 256 bytes to /dev/urandom (but does not
>>       accredit them yet, just remembers the amount written)
>
>How do you determine the number of bytes here?

32 + arc4random_uniform(256 - 32 + 1)

[…]
>The major input into the new seed file contents is the old seed file
>contents.  You are adding very little entropy on x86, and possibly
>almost none on other architectures.

This is during early boot, where there’s almost no entropy
available yet. This step, while having taken up a lot of
explanation, is mostly to ensure that the next seed differs
from the previous one.

The thing you missed is this:

>>• updates that in a daily cronjob (using same tool as during
>>  boot except with more bits taken from the kernel)
>>• updates (the second 64-byte half, from urandom) it on shutdown

Let’s take the second bullet point first: I’m adding 64 bytes from
whatever the system has in its RNG during shutdown. This is the
step where entropy for the _next_ boot is _normally_ added.

The early-rng-init-tools initramfs part is *not* about gathering
more entropy during boot, it’s to make whatever entropy is there
available earlier. (The regular /var/lib/urandom/random-seed (or
whatever systemd does) thing is *also* *still* done, just later.)

Now, the daily cronjob. It uses the same mechanism as in early
boot, but without the -E parameter, so it reads a few bytes more
from the kernel. On Linux, the exact numbers (modulo things like
dmesg and time which are only used to diversify) are:

• with -E (early boot):
  ‣ with AT_RANDOM
    – 16 bytes from AT_RANDOM (possibly shared with
      other code in the same executable)
  ‣ without AT_RANDOM
    – 4 bytes from /dev/urandom
  (although all of them are probably not very random)

• without -E (daily cronjob):
  ‣ with AT_RANDOM
    – 16 bytes from AT_RANDOM (possibly shared with
      other code in the same executable)
    – 8 bytes from /dev/urandom
  ‣ without AT_RANDOM
    – 16 bytes from /dev/urandom
  (and all of these are during normal system runtime,
  so should be random enough, otherwise you have a
  problem ANYWAY)

So, in the cronjob case, we get 128 to 192 bits from the
kernel. Tytso said that using 128 bits to initialise a
good RNG is probably enough for a lot… and we *do* also
add the 128 *bytes* (1024 bit) from the seedfile.

If the postinst (first time 1024 bits get written into
the seed file), cronjob (where the seed file is mixed
with another 128/192 bit from the kernel), shutdown
(where 512 bits in the seedfile are overwritten with
512 fresh bits from /dev/urandom) do not have entropy
enough, you have a different problem. Use something like
ekeyd with Simtec’s EntropyKey (which I do), or type more
on the keyboard, or, if you really must, use haveged or
something like that. My early-rng-init-tools does not
address that, you still have to ensure regular entropy
collection during normal system runtime happens and is
good enough. It’s really *just* about getting it usable
earlier in the boot process.

Perhaps you (or someone from l10n-en) could suggest
wording to that effect I could add to the package
description, or perhaps even a README? (Maybe I should
write a README anyway. I need to work on other stuff,
freeze/BSP-relevant but also real life-relevant, for
now, but I’ll revisit this anyway…)

I’ll take all feedback into account by then.

bye,
//mirabilos
-- 
16:47⎜«mika:#grml» .oO(mira ist einfach gut....)      23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)    23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren	-- Michael Prokop über MirOS bsd4grml