	Character driver for /dev/random. Marcus J. Ranum, 1993
	Trusted Information Systems, Inc.

	The goal of this driver is to provide a source of good randomness
based on crypographic hashing of accumulated time-specific state of the
system. A system specific library routine is invoked each time a read
is performed on the driver. This routine is expected to return a 128 bit
MD5 hash of time-specific system information (e.g.: the realtime clock,
VM page table entries, blocks in the buffer cache, network device queues,
or process states, etc) which is then XORed with the state of the previous
read against the device, and run through MD5. If more than 128 bits are
being read, the driver loops by adding a constant to each byte of the working
state, and re-hashing the result.

	This approach is expected to provide fairly good random numbers
because it folds time-specific information that is sampled whenever the
driver is accessed. Presumably the times at which the driver is accessed
are unpredictable, and the state of the system at the time when the driver
is accessed might be difficult to manipulate. Past sampling times should
"accumulate" so that after the system has been running for a while, the
values returned will be rather unpredictable. The reasoning behind tying
the driver into the kernel (and specifically process related stuff) is
to try to make it very hard for someone to 'capture' the state of the
system so that they could predict the seed of the random number generator.
Ideally, the effect should be similar to Heisenberg's uncertainty
principle: the act of measuring the system should change it enough to
make the measurement useless.

	The driver cannot address a situation where the systems manager
is tapping the kernel driver or its state.

	The driver consists of 3 parts, the (unmodified - md5c.c) MD5
sources, the character device driver itself (rand.c), and a system
specific "seed" routine (randsys.c) which can be tailored to gather
whatever good sources of fast-changing unpredictable information your
kernel may have. Randsys is expected to contain a function named:

void
rand_sys_specific(digest)
unsigned char   digest[];
{

	which is expected to take the 'digest' and fill it with an MD5
digest of some "interesting stuff." This is then Xored with the saved
digest from the previous run, and digested with MD5, then copied
piecewise into user space. The operation of the driver looks like





Installation Instructions:

	edit /sys/sun{3|4}/conf/{SYSTEM} and add:
	-----------------------------------------
pseudo-device   rand1

	edit /sys/sun{3|4}/conf/files and add:
	--------------------------------------
rand/rand.c             optional rand device-driver
rand/randsys.c          optional rand device-driver
rand/md5c.c             optional rand device-driver


	create directory /sys/rand and copy into it:
	--------------------------------------------
global.h
md5.h
md5c.c
rand.c
randsys.c

	edit /sys/sun/conf.c and add:
	-----------------------------
Near the top:
-------------

#include "rand.h"
#if NRAND > 0
extern int randopen(),randread();
#else
#define randopen        nodev
#define randread        nodev
#endif

Near the bottom, at the bottom of the declaration of cdevsw:
------------------------------------------------------------
    { 
        randopen,       nulldev,        randread,       nodev,          /*104*/
        nodev,          nulldev,        seltrue,        0,
        0,              0,
    },


	Note the number of the entry in cdevsw, it will be the major number
of the device.
	cd /dev
	mknod random c 104 0 #where 104 is the slot in cdevsw
	chmod 444 random
