Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!pesnta!amd!amdcad!lll-crg!hoptoad!gnu
From: gnu@hoptoad.UUCP
Newsgroups: net.crypt
Subject: Re: One time pads
Message-ID: <723@hoptoad.uucp>
Date: Mon, 21-Apr-86 22:30:43 EST
Article-I.D.: hoptoad.723
Posted: Mon Apr 21 22:30:43 1986
Date-Received: Wed, 23-Apr-86 22:52:05 EST
References: <484@ucsfcca.UUCP> <913@vortex.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 28

In article <913@vortex.UUCP>, lauren@vortex.UUCP (Lauren Weinstein) writes:
> To be truly useful, one-time pads must use VERY random data.  I doubt
> that "partial selection" systems (choosing bits from CDroms, etc.) would
> be adequate.  Real-world one-time systems tend to use the most random
> sources of bits they can find--like the rate of decay of certain
> isotopes.

Suppose you made your own CDROMs using isotopes to generate the data.
It does make a difference that you can put 600 MBytes of truly random data
onto a CDROM and slip it into a diplomatic pouch for delivery as next week's
cipher.  It would be hard to fit a large one-time pad into a battlefield
portable unit (eg on 6250 BPI 1/2'' tape) until CDROM.

If you have 600MB of true random data then it doesn't matter
much whether you send a little selector to pick WHICH random data
you are going to use -- it's already as random as it can get.

You have the usual key distribution problems of course -- if a Bad Guy
gets a CDROM then you are out of luck, as with all one-time pads.
Skipping around in it only slightly increases the work factor, but
complicates the key handling since the key is not only the CD ROM but
also the sequence in which to use pieces of it.

There *is* the problem that there are only a few factories in the world
that can make CDROMs but I'm sure the NSA won't object to spending some
tax dollars on building a private one of their own.
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa