Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: comp.arch
Subject: Re: random number generator in hardware
Message-ID: <7320@utzoo.UUCP>
Date: Fri, 14-Nov-86 20:14:34 EST
Article-I.D.: utzoo.7320
Posted: Fri Nov 14 20:14:34 1986
Date-Received: Fri, 14-Nov-86 20:14:34 EST
References: <317@zuring.mcvax.UUCP> <267@bath63.UUCP>, <2490@phri.UUCP>
Organization: U of Toronto Zoology
Lines: 25

> 	Which brings up a point which has been bothering me for a long
> time.  Why don't computers come with hardware random number generators?
> It doesn't seem like it would be too hard (i.e. expensive) to build a bank
> of 32 white noise generators hooked up to zero-crossing detectors...

My understanding is that the problem is avoiding bias in the resulting
numbers.  Building a noise generator isn't hard, but one would like the
probability of a 0 to be roughly equal to the probability of a 1.  Getting
this sort of balance, and *keeping* it, apparently is almost impossible
without constant tweaking.  It's viable for specialized applications like
generating encryption keys, but too much hassle to be built into every
computer.

I wonder, though, if it would be feasible to automate the de-biasing?
Each bit would have a counter, incremented on 1 and decremented on 0.
(This assumes that the bits change synchronously, or can be induced to
do so for counting purposes at least.)  Every 15 minutes, say, a daemon
would wake up and inspect the counters; those that were significantly
different from zero would indicate bias developing in those bits.  The
daemon could then adjust the noise generators via DACs.  Counter overflow
wouldn't be an issue provided it was remembered.  The daemon could do
arbitrarily sophisticated filtering to track things like component drift.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry