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 _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
