Some random links. Needs research.
It is like haveged but for earlier boot. Here;s the authorās description:
haveged tries to use CPU jitter, in a way similar to jytter but
on a much more massive scale, to gather entropy-ish and writes
that to the kernel RNG. It, however, does that all the time, and
not just a little bit. Basically, itās an attempt to gather entropy,
while early-rng-init-tools just takes whatās there during normal
system runtime (which you have to provide yourself, at the very
least before installing it, but sensibly also normally) and makes
it available to the kernel earlier (this really ought to be done
in the bootloader, even, but this at least improves on what we
currently have).
1 Like
This needs a through review. There is some criticism on the Debian mailing list that I might share. Qutoe the authors original post, for example:
ā£ uses that and a number of other things (to make it differ)ā¦
ā md5sum of dmesg
ā the current time
This might be completely predictable. And why md5sum if there is sha512sum.
If that speculation of mine is true, it might be dangerous if it does credit entropy.
Yet, early-rng-init-tools is very interesting as a concept and something useful might come out of it.
2 Likes
The way md5sum is being used is not vulnerable to collision attacks. However it is a shitty source of entropy. Easily accounted for without salting.
True. Perhaps the Twuerand rewrite can make use of some ideas it has.
1 Like
As the person who wrote early-rng-init-tools, I think I need to clean up some misconceptions here.
It is not, and isnāt designed as, tool to get better or more entropy.
Itās designed as a tool to get whatever entropy you have into the kernel as early as possible, until they get their arses together and introduce that into the bootloader ā kernel protocol.
What e-r-i-t does is:
- at boot, mount
/early on, load entropy from a file in the filesystem root, mix in stuff (see below), write back to the file and to the kernel PRNG - at installation and via cronjob, load the file (if existing) and entropy from the kernel and write the file again, so the next boot will have entropy available in said file
Now, the stuff mixed in is basically āwhatever we can get our hands onā. During normal system runtime, this is obtained from the kernel PRNG, easy enough.
During initramfs however thereās few entropy already available, so I grab the low-entropy-but-at-least-present things I can: whatever the kernel already has, whatever is in dmesg (MAC addresses come to mind, think cloned VMs), the current clocktime, a couple of bytes from /dev/urandom at update-initramfs time baked into the latter, and (on x86 only) a bit of jytter entropy. I am fully aware that these are no real source of entropy, a handful of bits and mostly predictable, but the idea is to mix them and the file from the filesystem together as āblindingā so that repeat boots from identical filesystems donāt get the exact same result. The mathematical entropy comes from the file in the filesystem.
If you can observe both that and the next bootās circumstances, you can predict the output, sure. But thatās not something this is designed to work against.
The goal of this is to do what /var/lib/urandom/random-seed (or its systemd equivalent) does, but as early as possible. Since there may not be much distinguishing information at that point or crashes can cause repeat booting with the same file, the extra blinding may help in some, select few cases (primarily for things like, you prepare a Banana Pi or something image, then many people download and run it, and they should get diverging info in the kernel RNG as early as possible, and the clocktime (if set) and devicesās MAC addresses are an acceptable way to do that).
Basically, itās a 90% solution, but should do no worse than not using it.
(In the initramfs, thereās no sha-anything-sum. Not reliably. I did look.)
2 Likes