Random numbers from CPU execution time jitter

Posted Apr 30, 2015 9:11 UTC (Thu) by shmget (guest, #58347)
In reply to: Random numbers from CPU execution time jitter by epa
Parent article: Random numbers from CPU execution time jitter

"The conventional wisdom is that hashing more entropy sources can't hurt: [...]
The conventional wisdom says that hash outputs can't be controlled; the conventional wisdom is simply wrong."

http://blog.cr.yp.to/20140205-entropy.html

to post comments

Random numbers from CPU execution time jitter

Posted Apr 30, 2015 10:09 UTC (Thu) by epa (subscriber, #39769) [Link]

But what if z comes from a malicious source that can snoop on x and y?

This is an interesting thing to consider but it is not usually that relevant. If my understanding of the article is correct, the assumption is that the attacker cannot snoop on the other entropy sources normally, but can somehow influence the generation of the new entropy source so that it takes into account the others.

So you would have to suppose some means of influencing the CPU jitter measurements that requires knowledge of another entropy source, but at the same time suppose that the other entropy source is not normally predictable by an attacker. This seems very far fetched.

The article goes on to make another argument: that adding more entropy is simply not needed. Once you have enough (say 256 bits) you can generate all the randomness from that. That may or may not be so, but it doesn't in itself add weight to the claim that adding new entropy sources is actively bad because they may be able to snoop on other sources (in some unspecified magical way) and so end up removing randomness from the result.

Random numbers from CPU execution time jitter

Posted May 3, 2015 9:44 UTC (Sun) by alankila (guest, #47141) [Link]

The attack outlined is probably not applicable to a entropy generator input situation. The key problem is that the inputs are likely to contain the current seed of the random number generator in some form. E.g. if you have some new data x you want to feed into the pool, a straightforward solution is to update the random number generator state with "state = H(state || x)" where H is a hash function returning suitably wide result. Since we are going to assume that the attacker is not already in possession of the seed, the attack is not possible.