Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 (Tek) 9/26/83; site orca.UUCP
Path: utzoo!linus!decvax!mcnc!unc!ulysses!mhuxl!ihnp4!alberta!ubc-vision!uw-beaver!tektronix!orca!andrew
From: andrew@orca.UUCP (Andrew Klossner)
Newsgroups: net.crypt
Subject: Re: secure codes
Message-ID: <574@orca.UUCP>
Date: Fri, 10-Feb-84 18:13:38 EST
Article-I.D.: orca.574
Posted: Fri Feb 10 18:13:38 1984
Date-Received: Tue, 14-Feb-84 01:19:11 EST
References: <239@vortex.UUCP> <620@nsc.UUCP>
Organization: Tektronix, Wilsonville OR.
Lines: 63

I'm not a cryptologist, but some recent comments as to why a one-time
pad are bad left me less than convinced.

	"1) they are not public-key.

	one time pads are only as secure as the distribution of the
	pads.  when you have to broadcast a message to many sites, the
	problem gets worse.  anyone who gets one of the one-time pads
	(which becomes even more likely when you have a large
	distribution) will ruin the security for that pad.  people who
	defect to the "other side" (whatever that means) can carry off
	such pads..."

With public key you "broadcast" by sending the message serially, once
for each recipient's key.  You can do the same with one-time pad, once
for each recipient's pad.

	"2) one time pads are very unforgiving on missing data

	the loss of a section of encrypted data will result in you
	getting off sync on your pad.  just think of would happen if
	you had to use such a system over uucp?  :-)   you can use sync
	marks to help reduce loss of information, but such sync marks
	are "give-away information" for code crackers too."

So you precede each word of encrypted information with its ordinal
number.  A cracker who receives the entire broadcast gains no
additional information, unless (s)he's unfamiliar with the set of
natural numbers :-)

	"3) when you need a large one-time pad, you almost have to
	    resort to a generation system of some kind.

	say you want a 1,000,000 unit pad.  how do you generate such
	data?  if you use random number generators of some kind, and
	the method of generation or even the style of generation gets
	known the pad security is greatly reduced.  you can overcome
	this problem by using static noise, or cosmic ray counts, but
	that is still not totally secure."

Agreed that you can't use a deterministic (programmable) random number
generator.  But what's wrong with a static noise count?  Why is it
"still not totally secure?"  Herein would lie the crux of the argument.

	"4) when you need to transmit a large amount of data, you must
	    use a large one-time key pad, distribute many pads, or
	    reuse the same pad.

	one time pads are best if they are short length, and short
	lived.  the longer used, or worse more often used, the less
	secure they become."

Agreed that you don't use the pad more than once, and that trusted
delivery of many one time pads is a problem, but what's the problem
with a big pad?  Noise doesn't become more intelligible in greater
quantity.

Would someone tell me what's *really* wrong with this scheme?  I can't
get comfortable with public-key; "uncomputable" doesn't mean anything
if the cracker has enough time and resources.

  -- Andrew Klossner   (decvax!tektronix!orca!andrew)      [UUCP]
                       (orca!andrew.tektronix@rand-relay)  [ARPA]