[Cryptography] [RNG] on RNGs, VM state, rollback, etc.

[Philipp Gühring]

Hi,


> >> Go ahead and mix in stuff like the RTC and the MAC address 
> >> if you want, but you'll have a hard time convincing anybody
> >> that such things are sufficient.

Why aren't more crypto projects are using HAVEGE? I would expect HAVEGE to
provide enough randomness fast enough so that it would be sufficiently
enough at boot-time, if implemented correctly.

https://www.irisa.fr/caps/projects/hipsor/

I have the feeling that HAVEGE is currently unmaintained, does anyone want
to maintain it?
I think a CPU is the only thing that is guaranteed to be available in a
computer, so in the absence of properly embedded hardware-RNG like the one
from Intel, from my point of view, something like HAVEGE should be the
second choice.

Or has anyone found any good reasons, why HAVEGE would be insecure or
problematic in some way, that I haven't heard about yet?
(Or is the Linux kernel already doing what HAVEGE did standalone in the past?)

I would like to invite everyone concerned about RNGs at boottime to take a
look at HAVEGE, to research it's security, to try to take over
maintainership of HAVEGE, and to try to port it to additional processors
where possible.

Another completely different idea I had for the boot-time scenario would
be to mix in the whole (or a part if it is too much) of the physical RAM
(/dev/mem) into the RNG pool at boot time, or on first demand when there
isn't enough in the pool already to satisfy the demand (so you don't need
to do it if nobody needs /dev/random)

Best regards,
Philipp Gühring