Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site mtxinu.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!mcnc!philabs!cmcl2!seismo!umcp-cs!gymble!lll-crg!dual!unisoft!mtxinu!ed
From: ed@mtxinu.UUCP (Ed Gould)
Newsgroups: net.crypt
Subject: Re: Why no hardware random numbers?
Message-ID: <321@mtxinu.UUCP>
Date: Thu, 21-Mar-85 13:41:08 EST
Article-I.D.: mtxinu.321
Posted: Thu Mar 21 13:41:08 1985
Date-Received: Tue, 26-Mar-85 04:59:18 EST
References: <868@utcsri.UUCP> <2139@wateng.UUCP>
Distribution: net
Organization: mt Xinu, Berkeley, CA
Lines: 16

>                      The problem with this type of random number generator
> is that the sequence of values you get is irreproducible, which can be
> a real drag if you are doing simulations and want to check your results,
> or you want to try two different algorithms on the same sequence of
> numbers.
> -- 
>    - peter bain

It seems, then, that we really need both.  A good software PRN
generator for testing, reproducing, and debugging, and a hardware RN
generator (I don't say pseudo-random, because I'm willing to define
certain natural phenomena as truely random) for better randomness.

-- 
Ed Gould		    mt Xinu, 739 Allston Way, Berkeley, CA  94710  USA
{ucbvax,decvax}!mtxinu!ed   +1 415 644 0146