From: maruishi@netcom.com
Date: Sun, 18 Feb 1996 13:44:54 +0800
To: Sandy Harris <sharris@fox.nstn.ca>
Subject: Re: True random numbers
In-Reply-To: <86934.sharris@fox.nstn.ca>
Message-ID: <Pine.3.89.9602172008.A20838-0100000@netcom19>
MIME-Version: 1.0
Content-Type: text/plain




On Sat, 17 Feb 1996, Sandy Harris wrote:

> 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
> 

Although using other networks probably isn't as safe as using your own LAN,
.....
If you send the packets across the US then there are more variables to
determine time they took to get back. This is obviously becuase each
and every machine in between well vary in speed, line connections etc...
And the timing even on the same machine well change, because of CPU laod
etc..

Maybe another "random" source XORed with this?
I don't know, just a though.

maruishi@netcom.com