Newsgroups: sci.crypt Path: cactus.org!ritter From: ritter@cactus.org (Terry Ritter) Subject: Re: IBM-PC random generator, source included Message-ID: <1992Jun23.080147.15804@cactus.org> Summary: Comments on Nico's RNG Organization: Capital Area Central Texas UNIX Society, Austin, Tx References: <2673@accucx.cc.ruu.nl> Date: Tue, 23 Jun 1992 08:01:47 GMT >It is a hardware based random generator (the hardware is the IBM-PC) >based on the jitter of crystals. To be able to "measure" it two crystals >are needed. Some extra tricks are needed to convert the partly deterministic >results of this fase to completely undeterministic data. Nico's RNG operates by incrementing a software counter in a tight loop. Periodic hardware "tick" interrupts sample the counter and save the current value into an array. The tick interrupt rate is increased by a factor of 64 to about 1165 ticks per second. When 32 values have been collected, the lsb's of each saved value are extracted and returned as a single 32-bit value. Potentially, random interrupts from some external source could slow the software counter irregularly, and yet have minimal effect on the counter/timer interrupts. But this would be a special situation. Note that the claim of "two" oscillator crystals is limited to AT+ designs. In the original IBM PC, a single 14.318 MHz crystal was divided to provide clock to both the CPU and the timer. Also note that crystal oscillators are deliberately intended to be stable; they *resonate*, and do not "jitter" (usefully). Using one crystal oscillator to sample another must be expected to produce fairly repeatable results, even if the results seem complex. Far less stable oscillators correlate usefully; this is how hetrodyne frequency conversion works. Of course Nico's RNG operates with periods of collection separated by other software execution, so the starting phases will be unknown in each collection period. There are 12 (remaining) bits of hardware counter phase, but only 1 bit of software counter phase (only the lsb is actually used), and anyway the software counter is initialized from the hardware counter before data are collected. So we have (at most) 12 bits of uncertainty (the unknown periods between collection) and 32 bits of result. In practice, I would expect to see some bit-by-bit predictability within each 32-bit sample, unless we have other interrupt effects. Some analysis is certainly possible, but it could be tough. --- Terry Ritter ritter@cactus.org