Subject: Re: NFS file handles are guessable.
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Perry E. Metzger <perry@piermont.com>
List: tech-kern
Date: 03/07/1997 13:14:21
Jason Thorpe writes:
> On Fri, 07 Mar 1997 09:26:53 -0800 
>  "Kevin M. Lahey" <kml@nas.nasa.gov> wrote:
> 
>  > Any ideas or plans to add /dev/random?  It sure would make things
>  > easier.
> 
> Well, plans to add a /dev/random -- sure, I'd love to have one...
> 
> ...but someone really ought to sit down and design an MI framework for
> gathering entropy :-)


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.

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