Subject: Re: NFS file handles are guessable.
To: None <email@example.com>
From: Marc Horowitz <firstname.lastname@example.org>
Date: 03/07/1997 17:07:49
"Perry E. Metzger" <email@example.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
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
I know Don, and have asked him for an online copy if one is available.
>> 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
>> 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.