Re: FYI/RFC: early-rng-init-tools
Thorsten Glaser writes ("FYI/RFC: early-rng-init-tools"):
> • during postinst, creates a 128-byte random seed file in /
Can you confirm that this is done with data from
getrandom(,,GRND_RANDOM) ? (Presumably with GRND_NONBLOCK too.)
> – after the root filesystem is read-write,
> ‣ reads from the seed file (128 bytes)
> ‣ uses that and a number of other things (to make it differ)…
> ← md5sum of dmesg
> ← 3 random bytes written into initramfs during update-initramfs
> ← the current time
> ← a bit of kernel entropy (from AT_RANDOM auxvec, set anyway)
> ← on x86, Jytter and the TSC
This latter stuff is fine but not really critical IMO.
> to initialise a stretching RNG (arc4random)
Why are you feeding this through a separate hashing function rather
than letting the kernel PRNG's hasher do it ? I am seriously
unconvinced that arc4random is a good idea here.
> ‣ writes between 32 and 256 bytes to /dev/urandom (but does not
> accredit them yet, just remembers the amount written)
Why not write the whole lot ?
> ‣ updates the seed file with 128 bytes from the SRNG
> ‣ fsync(2)s and close(2)s the seed file to ensure the next run
> will be different
Why not update the seed file with information from
getrandom(GRND_RANDOM), instead ? (You would have to do this after
the next step.)
> ‣ now tells the kernel X random bits were added, where X is…
> → the number of bytes written earlier…
> → times 6 (so we count at best six bits per byte)…
> → capped at 128*7 bits, to both not overwhelm and because our
> seed is only 128 bytes in size, estimated conservatively
IMO you should promise to the kernel an amount of entropy exactly
equal to the size of the saved seed.
> I am fully aware that it is not suitable for everyone:
> • it’s Linux-only (the RNG on kFreeBSD is very different, and
> I didn’t even look into Hurd’s urandom translator)
I think the same principles will apply. If your utility on BSD uses
BSD's /dev/random instead of Linux's getrandom() syscall, then it will
DTRT.
> • it prevents you from booting with / mounted read-only
I think this is an undesirable side effect. There is a tradeoff here:
If you defer updating the seed to later, after you have already set
off the kernel RNG, then any situation with multiple partial boots
will reuse the seed, which is bad. Whether that's a practical problem
depends on what exactly might be run in the meantime, with / still ro.
I missed the beginning part. Is it not possible to defer all of this
to make it run just after / is mounted rw ?
> • it means you trust a seed file and the arc4random algorithm (to make
> a uniform enough stream from the various seeds)
The question is nothing to do with its uniformity. The kernel PRNG
will hash its input. I think you can feed it whatever.
If the RC4 were critical to the security properties of your scheme,
then I would be making a much stronger complaint, because RC4 is (of
course) broken (when used as a supposedly cryptographically secure
pseudorandom bitstream generator).
I hope you have found this review helpful.
Regards,
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: