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

[Philipp Gühring]

Hi,

> A cursory look at the HAVEGE papers tells the following story : as a user i don't have access to the entire internal state of my cpu and since the time needed to execute a given instruction is a function of both the instruction and the cpu state measuring the time gives me entropy.
>
> I might have a few issues with that. First the fact that intel didn't give me access to the entire cpu state does not mean that they haven't given the NSA the opcode to do just that. Then, since we never get access to the cpu state we don't actually have a formal model guaranteeing that the lsb of the tick counter are actually random. 
Hmm, if someone is able to run secret opcodes, then we already have
local code execution, right? And in this case there might be far more
powerful secret opcodes that give ring 0, ring -1 , ... access, and we
usually have to care about much larger problems than RNG attacks.
So if I compare it to the network-traffic -> interrupt -> RNG concept,
where attackers can gain information about the RNG by observing or
manipulating the network, without having local code execution, I think
HAVEGE is more safe due to requiring local code execution  to be attacked.

Do you really see a threat-model against RNGs where someone can execute
opcodes to get more information about the cpu state? If yes, please
explain further.

> I generally feel uneasy calling unpredictable a deterministic process and then imposing that the adversary is stupider than me. That being said i wouldn't have a problem feeding all that into /dev/random while crediting 0 entropy.
Which one do you prefer? A RNG provided by the CPU vendor, or a RNG that
was developed independently from the CPU vendor, or an RNG that can be
influenced with network traffic? (I prefer a mix of all of them)
I would suggest to credit it 0.0001 entropy for mixing it into
/dev/random, and I guess that this might be enough for /dev/random to
have enough entropy almost all of the time.

> As far as your idea of feeding ram into the entropy pool I fear that because of the remanence  effect you could actually be feeding adversarially controlled input into the entropy pool. Also if the idea is to resolve the "first-boot" issue then it assumes the RAM has uncertainty which I m not sure is true ( i would be even less confident of that in VM)

Shouldn´t a good mixing / whitening function care about adversarially
controlled input?

Well, I would expect the RAM to contain all of:
* Kernel image (which should be different after every kernel update)
* MAC address
* ACPI/Bios/UEFI tables
* various serial numbers of various internal devices like chipset,
RAM-chips, realtime-clock, ...
* Information about USB devices that are currently attached, ...
* Current date+time
But I did not investigate yet, whether that´s the case.

Best regards,
Philipp Gühring