1996-02-18 - Re: True random numbers

Header Data

From: “Sandy Harris” <sharris@fox.nstn.ca>
To: cypherpunks@toad.com
Message Hash: a90fe3de802e6dc12f0ba36e94454d1ec84fb4fd9dfea7a3c751645886e41456
Message ID: <86934.sharris@fox.nstn.ca>
Reply To: N/A
UTC Datetime: 1996-02-18 02:47:16 UTC
Raw Date: Sun, 18 Feb 1996 10:47:16 +0800

Raw message

From: "Sandy Harris" <sharris@fox.nstn.ca>
Date: Sun, 18 Feb 1996 10:47:16 +0800
To: cypherpunks@toad.com
Subject: Re: True random numbers
Message-ID: <86934.sharris@fox.nstn.ca>
MIME-Version: 1.0
Content-Type: text/plain


Deranged Mutant  <wlkngowl@unix.asb.com> wrote:

>maruishi@netcom.com wrote:
>> 
>> I was trying to think of a way to come up with true random numbers...
>> And knowing a bit of UNIX socket TCP/IP programming I made a small [..]
>
>I wouldn't trust the samples taken from networked sources.

Me neither, in general.

A possible exception: I wonder if the checksums on Ethernet or IP
packets use a reasonably strong CRC algorithm. If so, they might be
a decent source of randomness in an environment where you could be
sure the Black Hats couldn't see them. e.g. using only packets from
your own LAN, suitably protected by firewall & good administration.
 
>You're better
>off with a kernel patch that samples from local sources directly like 
>disk or keyboard timing variations... such patches already exist, with 
>similar drivers developed for DOS and OS/2 systems as well.

I'd be more inclined to hash the kernel's internal tables, e.g. process
& file descriptor tables. These should vary quite a lot & if the enemy
can see them, random number quality is the least of your worries.

RFC 1750 is a good reference on this problem.
 --
 Sandy Harris
 sharris@fox.nstn.ca





Thread