Re: FYI/RFC: early-rng-init-tools
I think the only sane things are:
- Use a hardware RNG (CPU, TPM, chaos key, ...)
- Credit a seed file stored during the previous boot
- Wait for new entropy from other sources
Note that is can be a combination of all 3.
We currently do not credit the seed file, for various good
reasons. We should provide an option to users that need it to
trust that file and credit that file. Note that it does not need
to be fully trusted, we could for instance say it only provides 64
bits of entropy.
Most people will actually have at least 2 hardware RNGs: One in
the CPU and one in the TPM. We can make the kernel trust those as
entropy source without using something in userspace to feed it.
I'm not sure in the kernel has the option to use the TPM directly
as source, but it makes it available as /dev/hwrng. (The TPM might
be disabled in the BIOS.) Some people don't trust them, I suggest
they buy something they do trust, and disable the ones they don't
trust. I think we should trust all hardware RNGs by default, and
then also actually extract data from all of them.
Note that the internal state of an RNG is only 256 bit / 32 byte.
If you make that output something, it can't have more than that 256
bit of entropy. It does not make sense to take more bytes of the RNG
than that to feed back in it. It can make sense to do this at
different times, after the RNG has reseeded, but both should be
limited to that 256 bit / 32 byte. It doesn't make sense to do
this at more than 2 different points in time.
There is no point in using an other RNG to stretch something. Just
use the kernel RNG to stretch it by just asking more data from it.
Do not feed the output of the kernel during boot back into the
kernel, even if you don't credit it. If there is something random
in it, the kernel will already have used that. If you do it, there
is no point in using something like md5, the kernel will take care
of that itself.
Other than the entropy you feed it, it can be useful to feed it
data that does not need to be secret but is very likely different
on each boot, including things like the current time, and an
incrementing counter. It would not be credited as having entropy.
The seed file currently acts as this. I have no idea if the kernel
does anything like that itself, like the mount count of a
filesystem. It might be useful that we feed it some boot counter.
Kurt
Reply to: