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