"Perry E. Metzger" <perry@piermont.com> writes:

>> The general mechanism one uses these days is note the low bits on a
>> high resolution timer when you get in certain kinds of interrupts
>> (like keyboard interrupts) and to then mix and distil the bits with
>> SHA.

At Crypto '94, Don Davis et al described a technique for generating
random numbers by sampling disk access times.  Turbulence causes the
access times to have a truly random component, which can be filtered
out and used.  IIRC, some of the original work was done on a vax bsd
kernel; even if we can't get this code, the concept is still valid,
and it would be very cool to collect real, non-pseudo, random numbers
and make them available via /dev/random.  If we're lucky, the MI disk
code is sufficient, and we can finesse the entire issue of MD/MI code.

Here's the reference:

   [DAVIS] - Cryptographic Randomness from Air Turbulence in Disk
   Drives, Advances in Cryptology - Crypto '94, Springer-Verlag Lecture
   Notes in Computer Science #839, 1984, Don Davis, Ross Ihaka, and
   Philip Fenstermacher.

I know Don, and have asked him for an online copy if one is available.

		Marc

>> 
>> The SHA part is important. Most of the bits of the timer output will
>> not be "random". However, given a guess on how "nearly" random the
>> timing is, you can use a hash function like SHA to "distil" the
>> entropy from these events.
>> 
>> We need:
>> 
>> 1) an MI interface to a high speed counter/timer, such as, say, a
>>    macro to access a CPU instruction counter if one exists. If there
>>    isn't such a low cost/high resolution timer available, microtime
>>    could be used (but its best to avoid that if a better timer is
>>    available.)
>> 2) an MI mechanism for associating a given number of bits of entropy
>>    with a given interrupt. Interrupts for which the number is near
>>    zero (such as the clock interrupt) or for which you don't trust
>>    that an opponent couldn't guess the timing (like network card or
>>    similar interrupts) don't get mixed in.
>> 3) A kernel accessable set of hash functions -- SHA-1 is probably the
>>    best to use. This can also be used by things like the TCP ISS
>>    generating code.
>> 
>> We also probably want to build two sets of "random" output -- a "low
>> quality" source of random numbers that is created by seeding a
>> cryptographic quality PRNG -- this is suitable for frequently needed
>> but not ultra-critical numbers like the ones used for inode generation
>> numbers, and a "high quality" source used for things like periodically
>> re-seeding said PRNG, providing a secret for RFC1948 style TCP ISS
>> generation, handing userland programs like SSH cryptographic quality
>> RNGs for RSA key generation, etc.
>> 
>> Perry
>>