On 10.02.2013 19:50:02, +0100, Theodore Ts'o <tytso@xxxxxxx> wrote: Hi Ted, > On Sun, Feb 10, 2013 at 01:46:18PM +0100, Stephan Mueller wrote: >> However, the CPU has timing jitter in the execution of instruction. And >> I try to harvest that jitter. The good thing is that this jitter is >> always present and can be harvested on demand. > How do you know, though, that this is what you are harvesting? ... Given all your doubts on the high-precision timer, how can you reasonably state that the Linux kernel RNG is good then? The data from add_timer_randomness the kernel feeds into the input_pool is a concatenation of the event value, the jiffies and the get_cycles() value. The events hardly contains any entropy, the jiffies a little bit due to the coarse resolution of 250 or 1000 Hz. Only the processor cycles value provides real entropy. Now you start doubting that with arguments that the resolution of that processor cycle timer is very coarse. If this is the case, why shall I trust random.c, especially considering the measurements observable events like key strokes, mouse movements, interrupts (network cards). Only if you have a high-precision time stamp, entropy can be derived from these events. Moreover, I cannot understand your comments on VMs -- on x86, the timer depends on the rdtsc instruction which should be available on current CPUs and is callable from user space. Hence, there should be no obstacle to use this instruction within a VM and get a good reading. Note, I will make measurements about the distribution of the timer values and will come back to you. Thanks Stephan -- | Cui bono? | -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html