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
