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 <ijack...@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.
