On Sun, Feb 10, 2013 at 1:50 PM, Theodore Ts'o <ty...@mit.edu> wrote:
> 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? > ... > And what's your proof that your entropy source really is an entropy > source? One paper that seems to show there is some randomness in such measurements is McGuire, Okech & Schiesser "Analysis of inherent randomness of the Linux kernel", http://lwn.net/images/conf/rtlws11/random-hardware.pdf They do two clock calls with a usleep() between, take the low bit of the difference and pack them unmixed into bytes for testing. Their tests show over 7.5 bits of entropy per byte, even with interrupts disabled. The same paper shows that simple arithmetic sequences give some apparent entropy, due to TLB misses, interrupts, etc. There are lots of caveats in how this should be used and it is unclear how much real entropy it gives, but is seems clear it gives some. My own program to feed into random(4) is based on such things: ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/ HAVEGE also uses them http://www.irisa.fr/caps/projects/hipsor/ & there is a havegd daemon for Linux http://www.issihosts.com/haveged/ random(4) also mixed in timer data at one point, which seems the correct thing for it to do. Later I heard something about that code having been removed. What is the current status? -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
