From: Mark Murray <mark@grondar.za>
Date: Wed, 1 Nov 1995 07:12:33 +0800
To: "Theodore Ts'o" <tytso@MIT.EDU>
Subject: Re: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
Message-ID: <199510312115.XAA06361@grumble.grondar.za>
MIME-Version: 1.0
Content-Type: text/plain


>  In a 386 or a 486 (under FreeBSD at least) there is a 1Mhz clock available.
>  How would _this_ be? On the Pentium there is the <whatsit?> register
>  which will give the board's oscillator (or 90 MHz) I believe.
> 
> What's HZ set at for FreeBSD?  Most of the x86 Unixes have generally
> used HZ set at 100, because the interrupt overhead on a x86 isn't cheap,
> and so you want to limit the number of clock interrupts.

There are two interrupts 100Hz and the other 128Hz (The second gets pushed
into the +-1K region during profiling.

> You can sample the timing clock, but it turns out to be rather expensive
> to do so; several I/O instructions, which will require several delays if
> they have to go through your 8 MHz ISA bus.  We've moved away from using
> the hardware clock on the 386 because of the overhead concerns.  On the
> Penitum, we use the clock cycle counter.

Drat. Methinks I need to follow suit, but I value that 1Mhz...

> Well, verifiable randomness really is like gold.  It's a valuable
> resource.  On a time-sharing system, where you really want to equitably
> share *all* system resources perhaps there should be a quota system
> limiting the rate from which a user is allowed to "consume" randomness.

True. VMS could probably do this. <Ducks bricks>

> On the other hand, most Unix systems *aren't* great at doing this sort
> of resource allocation, and there are enough other ways of launching
> denial of service attacks.  "while (1) fork();" will generally bring
> most systems to their knees, even in spite of limitations of the number
> of processes per user.  Most Unix systems don't protect against one user
> grabbing all available virtual memory.  And so on....

Getting there (I think).

> There's nothing special about /dev/random in this sense; it's just
> another system resource which can be abused by a malicious user, just
> like virtual memory or process table slots.

True. Good policing never hurt.

>    This is a strong argument for some form of specialised noise source.
>    I have read of methods of getting this from turbulent air flow in a hard
>    drive (an RFC, I believe).
> 
> Yes, ultimately what you need is a good hardware number generator.
> There are many good choices; from radioactive decay, noise diodes, etc.

The idea that I like the most so far is to generate noise, but filter
it through an LPF to get frequencies less than (say) 500Khz. Put that
through schmitt trigger to get decent squarewaves and then into an
N-bit hardware shift register with some XOR feedbacks to mix this.
Voila! Nice numbers on demand. Shouldn't cost more than a few <shekels>...

> Short of good hardware sources, the other really good choice is
> unobservable inputs.  Hence, the Linux driver is hooked into the
> keyboard driver, and the various busmice drivers.  Those are really
> wonderful sources of randomness, since they're generally not observable
> by an adversary, and humans tend to be inherently random.  :-)

Doesn't work on servers in locked rooms... :-(
With those, as long as the machines are secure, (ie plebs cannot watch
and time raw packets) the network card is OK. The server may not be on
transit ethernet AT ALL.

M
--
Mark Murray
46 Harvey Rd, Claremont, Cape Town 7700, South Africa
+27 21 61-3768 GMT+0200
Finger mark@grumble.grondar.za for PGP key