Date: Wed, 19 Jul 2000 11:33:55 -0600 From: Warner Losh <imp@village.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Mark Murray <mark@grondar.za>, current@FreeBSD.ORG Subject: Re: randomdev entropy gathering is really weak Message-ID: <200007191733.LAA82735@harmony.village.org> In-Reply-To: Your message of "Tue, 18 Jul 2000 08:56:57 %2B0200." <7469.963903417@critter.freebsd.dk> References: <7469.963903417@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <7469.963903417@critter.freebsd.dk> Poul-Henning Kamp writes: : In message <200007180652.IAA04139@grimreaper.grondar.za>, Mark Murray writes: : >> No, he doesn't have access to the offset from the machines local clock. : >> : >> I ran a quick & dirty test here on some logfiles: that offset is : >> very close to white noise. : > : >With what amplitude? : : Depends on the termal environment of your xtal obviously :-) Poul, what's the Allen Variance for the sample that you measured? That's going to be the quality of the two oscillators under measure. Here we see correleations on the order of 10e-15, but that's for really good cesium clocks :-). For PC hardware, these differences are going to be effectively random. Why? The quartz xtals in them are usually really really bad. They drift all over the place with temprature, humidity and all kinds of other factors. Even tiny changes in temperature can be measured in the resulting frequency change of the OSC. Temperature near the xtal can vary quite a bit due to the vagaries of PC hardware. The drift of your clock is going to be effectively random. Sure, you know that what range it will be in, but from moment to moment, you don't know what the silly thing will do. I'm not sure how many random bits we can harvest from these measurements, but they are a good source of at least a few bits. All the data I've looked at is for high precision clocks or at least temp controlled xtals, which have much smaller variations. Another good source would be if you had a Cesium clock and a GPS receiver. The delay due to atmospherics is another good source of random data. This varies +- 25ns and is highly locale dependent. One can measure this variance down to the nanosecond easily (giving about 5 bits of randomness) and with a lot of effort down to the pico second level, which would give you about 15 bits of randomness. When you are measuring the offset of two clocks that have been operating independently for a period of time, you'll find that the offset is effectively random. Since I think that ntp uses a one way time measurement, you will know the original time, the time on the remote, and maybe the approximate time that the packet returns. You can make low resolution estimates of the total delay and calculate an offset based on that. However, if the clocks are already close the delay almost always swamps the offset and your estimates of delay will be so far off that you'll not be able to estimate more than a few of the high order bits, if you are lucky. It certainly would be better than nothing and would be a decent source of randomness. It would be my expectation that if tests were run to measure this randomness and the crypto random tests were applied, we'd find a fairly good source. Warner Losh Timing Solutions http://www.timing.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007191733.LAA82735>