On 03/03/19 17:59, Kurt Roeckx wrote: > 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. No. This may be true for AMD64 but this is not the case for other platforms 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. > yes - if there is a HRNG we should use it by default. if the user DOES not want to use this then they are free to disable it (we need to ensure that this is not a complex procedure) > 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. agreed - it provides a 'delta' that is especially useful for VMs (Serial numbers and MACs may be useful sources of 'psudo uniqueness' here > 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 > > /Andy
Attachment:
signature.asc
Description: OpenPGP digital signature