[cryptography] Mixing RdRand with other CPU-based entropy sources?

Stephan Mueller smueller at chronox.de
Thu Dec 19 04:55:41 EST 2013


Am Donnerstag, 19. Dezember 2013, 09:58:06 schrieb Natanael:

Hi Natanael,

>It's always a good idea to use several entropy sources and
>cryptographically mix their outputs into your pool. They won't reduce
>your total entropy either way, any predictable sources will only be
>adding less entropy than promised.
>

I would not concur with this statement, if the entropy collection 
process implies or heuristicially estimates some value of entropy 
associated with the incoming information.

Assume you have two noise sources which draw more or less from the same 
phenomenon (like Haveged and my proposed Jitter RNG which both use CPU 
execution time variations), which independent of each other would 
produce a bit stream with some entropy X and Y. Now, you have a 
collection process which draws from both noise sources at more or less 
the same time, as a baseline (i.e. unless you can prove otherwise) you 
must assume that there are some dependencies / correlations between 
these two bit streams. That means, your entropy collector cannot assume 
that the two bit streams have the combined entropy of X + Y, but that 
combined entropy is expected to be less as a baseline (i.e. unless you 
have a rationale why you still have an independence).

That said, using the CPU execution time variations as a noise source, 
all my research showed that each measurement is independent of the 
previous measurement. That said, even two noise sources running in 
parallel (which means that they never truly execute in parallel on the 
same CPU) are always independent. So, the use of two different 
implementations drawing from the CPU execution time variations should be 
ok.

You clearly see that particular problem with /dev/random and the newly 
introduced fast_pool. The noise sources for HID and block devices also 
always generate interrupts. Now, it is important that the interrupt 
noise collection function is implemented in a way that breaks its 
dependency/correlation to the other noise sources. That is (hopefully, 
but I have not seen any analysis yet) achieved with the fast_pool that 
collects and mixes at least 64 interrupts before mixing its state into 
the input_pool. Furthermore, you see that also in the fact that any mix 
of fast_pool into input_pool is assumed to only provide 1 bit of 
entropy.

Ciao
Stephan


More information about the cryptography mailing list