At 03:46 PM 9/30/95 -0400, you wrote: ... <deletia> ...
The basic idea is that you exploit randomness in the drift between the processor clock and the rate at which interval timer interrupts occur. Such drift occurs even on idle processors. randbyte() assumes that there's at least about .4 bits of "entropy" per interrupt, which is (probably) a safe assumption on modern processors. Randomness introduced by the OS (scheduler, etc.) can add to the overall entropy, but shouldn't be relied upon by itself.
An advantage to this approach (using clock skew) is that the randomness doesn't depend on external events like user input, network traffic or processor load. That makes it especially attractive for generating keys on unattended servers, e.g., for generating Diffie-Hellman exponents. Note, however, that very (very) slow and heavily-loaded processors may not provide enough cycles to the truerand process between interrupts for these assumptions to hold. Also, all bets are off on processors that use a single clock source for both interval timing and CPU clocking.
Even with the exclusion of processors using single-source clocking for interval and CPU timing, this would *seem* to be somewhat hazardous. Any two clocking mechanisms that are 'mixed' are going to result in a number of harmonics, or beat frequencies. While your system - at any given instant - is quite likely to have a decent amount of randomness in it, I'd hazard a guess that repetitive use would result in a discernible pattern. Even something as 'coarse' as an interrupt timer has a finite range that it can (must) operate in. Even if the CPU oscillator is based on a ceramic resonator (nowhere near as stable/accurate as a crystal), the clock on it is going to stay within +/-1% (worst case, for a *really* cheap oscillator) of frequency, and drift not more than some number of Parts Per Million per Period. Mixing the innate (relative) accuracy of two oscillators, and the necessarily limited amount of drift that they're capable of, would seem to result in an unacceptably low-yield source of 'real' randomness. Of course, I'm kind of math-impaired when it comes to crypto, so my 20+ years of electronics (hardware) experience may not apply in this case :-) Dave Merriman This is a test (3 UUE lines) of the unconstitutional ITAR - 1/713th of the PGP executable. See below for getting YOUR chunk! ------------------ PGP.ZIP Part [015/713] ------------------- M=$<(&L`#*IPP",(G6(,,S,`P](<2RWU96XCW86/JBYV8A\D8@X'HB_9H#&\X MX'PCUB.,13B"X8`R?^J-:UB.M_`U\>[#)BS&5$0C,Y#^1CS>1`\T1QTXX6!3 M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/ <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> My web page: http://www.geopages.com/CapitolHill/1148