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

[Alexandre Anzala-Yamajako]

> 
> 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
> 
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography

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. 

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.

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)

Cheers