Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!mcnc!unc!ulysses!mhuxr!mhuxn!ihnp4!ltuxa!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: net.crypt
Subject: Re: One-time pads, military field communication
Message-ID: <871@ttrdc.UUCP>
Date: Sat, 10-May-86 15:31:19 EDT
Article-I.D.: ttrdc.871
Posted: Sat May 10 15:31:19 1986
Date-Received: Tue, 13-May-86 05:43:00 EDT
References: <3264@reed.UUCP> <6650@utzoo.UUCP> <507@ucsfcca.UUCP>
Organization: AT&T, Computer Systems Division, Skokie, IL
Lines: 32

In article <507@ucsfcca.UUCP>, dick@ucsfcca.UUCP (Dick Karpinski) writes:
>Why are one time pads impractical in military field communications?
>If a CD ROM holds 500 megabytes of key in a drive like the ones that
>joggers are happy to wear on their belts,  I see no hard problems.
>
>Dick Karpinski    Manager of Unix Services, UCSF Computer Center

Question[s].  Given the one-time pad, how does the receiver of the encrypted
message know which "sheet" of his pad to use as the decryption key?  Is
this information (sheet number of pad) sent as "clear" information (or
encrypted using another kind of key)?ZZ

Also, in a situation where a sent message from a one-time pad might not
always succeed in being received, how can it be guaranteed that the pad
will truly remain "one-time", that is, someone else will not use the
same sheet in their copy of the pad that the unsuccessful sender used?
Maybe sheet number to use in the pad is based on the time of transmission?

In any case, there is an obvious security problem if a man out in the field
carrying one of these pads happens to be captured by the enemy; many copies
of the pad would need to be carried, wouldn't they, to make the scheme
useful for field communications?  (Of course the unit could have an "erase"
button on it for emergency data destruction, but that doesn't help much if
the soldier is killed in action and the body captured.)
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
						vax135}!ttrdc!levy