🚀 go-pugleaf

The crucial thing is, that after chernobyl you don't need a radiactive
source any longer - it's now perfectly distributed over europe.
Think of the view that the chernobyl accident was a beta test for a
enormous random generator which was generously donated as freeware :-(
	HaL
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ The usual disclaimer : It wasn't me, somebody must have used my account ... ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ UUCP/Usenet   :   {known world}!seismo!mcvax!cernvax!ethz!lubich            ~
~ CSNET         :   lubich%ifi.ethz.chunet@{relay.cs.net, csnet-relay.csnet}  ~
~ ARPA          :   lubich%ifi.ethz.chunet@csnet-relay.arpa                   ~
~ VOICE         :   +41 1 256 52 53                                           ~
~ MAIL          :   Hannes Lubich, Institut fuer Informatik, SOT C13          ~
~                   ETH-Zentrum, 8032 Zuerich, Switzerland                    ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In article <434@ethz.UUCP>, wyle@ethz.UUCP (Mitchell Wyle) writes:
> An unnamed organization uses the following paradigm to pass secure
> information electronically:
> 
> Random bits, generated from a radioactive source and calibrated counter
> are collected, and distributed by courier to remote sites.
> 
> Messages are encoded via bit-wise exclusive-or, and transmitted via
> non-secure telecommunications.  The destinations use the courier-provided 
> random bits from the key tape to decode the messages.  Each bit is
> discarded after use.  Every few months, a new tape is sent by courier.

I was a participant in a startup company which produced a small, battery
powered machine which automated the above process.  (OK, we didn't
use radioactives- but we did take the trouble to balance our shot-noise
and then check for possible "tampering" by performing an entropy measurement
on every 4K block of keytape).  Including a battery powered acoustic
modem, a tiny printer, LCD display, keyboard, and a box of ten keytapes, 
it was smaller and weighed less than a copy of the CRC.
	
Your big problem is going to be a known-plaintext spoofing attack.  
If you can find out (or guess, because you've seen the plaintext of
several other transmissions and KNOW they always start with the
date, time, city of origin and sender's full name and title, in standard
format)  then you can XOR your guess against the transmitted block
and get back a good guess for the key FOR THAT BLOCK ONLY.  Given
that key, you can spoof (fake) a transmission OF THE SAME LENGTH.
You don't gain enough info to spoof the next block, however.  

To stop this, we had two checksums - an exterior one to verify that the block 
was transmitted correctly, and an interior one which checked for tampering,
spoofing, and known-plaintext attacks.  The probability of a known-plaintext
(or chosen-plaintext ) spoof succeeding (because of the way the interior 
checksum was generated) was one chance in 2^32.
	
Well, nobody wanted to buy our boxes... until an overzealous sales rep
tried to make a sale to Ghana!  (We had previously warned him NOT to sell
to foreign nationals or governments).  Well,  the entire R&D team (self and 
3 others) went down to the local FBI office and sang like canaries.
Case (and company) closed.
	
Conclusion - The straight XOR system can be spoofed GIVEN that the content
of a message can be guessed or is known beforehand.  That's the weakness.
If the uncertanty of the message is high, and the uncertainty of the 
keytape is complete, the system works.  (beware - an oversmplification
exists in the above conclusion.  Read a text on information theory
(such as Pierce's _Symbols, Signals, and Noise_ and you'll understand))

Second weakness - bribe a courier.  Any tape that can be read can
be read twice (or duplicated onto two simultaneous tapes).

Third weakness - Are the two "ends" (coderooms, computer rooms, terminals)
completely secure?  As in TEMPEST?  Like a copper room with a copper door?
How about the bozos who work there?  Can they be trusted?
 
	
	-Bill Yerazunis
	
	"I don't think we need any NSA line eater food on
         *this* message "
	

The easiest way to compromise an exclusive-or cryptographic scheme with
courier-distributed key is to bribe the courier and make a copy.  This
cryptographic scheme is also very inefficient in that you have to
transmit the same amount of data via courier as you do over the
communication link.

As for the "randomness" of radioactive decay counters, I recall that one
was installed on M.I.T. Lincoln Laboratory's TX-2 computer around 1959
and was used for serveral years before someone discovered through
statistical analysis that it was decidedly non-random.  The problem was
traced to an obscure asymmetry in a critical circuit, as I recall.

In article <434@ethz.UUCP>, wyle@ethz.UUCP writes:
>An unnamed organization uses the following paradigm to pass secure
>information electronically:

PARADIGM?  What PARADIGM?  Sounds like a METHOD to me....

>Random bits, generated from a radioactive source and calibrated counter
>are collected, and distributed by courier to remote sites.
>Messages are encoded via bit-wise exclusive-or, and transmitted via
>non-secure telecommunications.  The destinations use the courier-provided 
>random bits from the key tape to decode the messages.  Each bit is
>discarded after use.  Every few months, a new tape is sent by courier.
>They will, of course, move to optical disk soon to decrease courier
>trips, and allow for increased bandwidth.
>How is the system flawed?  Is it unbreakable?  Couldn't companies
>implement this strategy cost-effectively?

Is this not just an implementation of a "one-time pad"?

>                      M i t c h e l l     F     W y l e
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|            dan levy            |  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,
                                        allegra,ulysses,vax135}!ttrdc!levy

In article <434@ethz.UUCP> wyle@ethz.UUCP writes:
>An unnamed organization uses the following paradigm to pass secure
>information electronically:
>
>Random bits, generated from a radioactive source and calibrated counter
>are collected, and distributed by courier to remote sites.
>
>Messages are encoded via bit-wise exclusive-or, and transmitted via
>non-secure telecommunications.  The destinations use the courier-provided 
>random bits from the key tape to decode the messages.  Each bit is
>discarded after use.  Every few months, a new tape is sent by courier.
>They will, of course, move to optical disk soon to decrease courier
>trips, and allow for increased bandwidth.
>
>How is the system flawed?  Is it unbreakable?  Couldn't companies
>implement this strategy cost-effectively?

This is called the one-time-pad.  It is perfect (if you have a perfect
random number generator that is).

The problems are these:  You need a secure communications channel to
transmit the key.  The keys are *very* long.  You need a different key
between every sender-receiver pair unless you trust *all* your stations
completely.
		-ed falk, sun microsystems
terrorist, cryptography, DES, drugs, cipher, secret, decode, NSA, CIA, NRO.
(The above is food for the NSA line eater.)

In article <434@ethz.UUCP>, wyle@ethz.UUCP (Mitchell Wyle) writes:

> Random bits, generated from a radioactive source and calibrated counter
> are collected, and distributed by courier to remote sites.

> Messages are encoded via bit-wise exclusive-or, and transmitted via
> non-secure telecommunications.  The destinations use the courier-provided 

This is an example of the "one time pad", the only unbreakable system.
The only points of attack are the random source and the couriers.

random source	- develop a unified field theory allowing you to reconstruct
		the output of the radioactive source after stealing the
		sample temporarily for analysis.

couriers	- offer them moolah, threaten with death, etc.  (much
		cheaper than the above.
-- 
Stuart D. Gathman	<..!seismo!dgis!bms-at!stuart>

[ ethz!wyle describes a encryption scheme based on random keys and asks:
> How is the system flawed?  Is it unbreakable?  Couldn't companies
> implement this strategy cost-effectively?

  This system is essentially a one-time pad system.  It is not breakable
in the sense of never having to re-get the random-bits.  However, that does
not mean that it is a totally secure system.  If the "pad" -- here it is the
(1) source of the random bits; (2) the storage of the random bits on a
copyable medium; (3) transmission of the the random bits by a supposedly
reliable courier and (4) both the reading and writing of the random bits
on the medium -- is kept secure, the system is a good way towards security.
And, if it is not kept secure, too bad.

  However, let me suggest some possible drawbacks:

   1. What constitutes a message?  Are there specified lengths of messages?
      Are there always headers or trailers to every message?
      What error-correction/detection features are used?  If a
      message arrives in error, what happens?  A nasty person knowing
      this information might be able to do a plain-text attack or 
      other cryptanalytic [note, this word is easy to write but very
      hard to say -Bob] attack.

   2. Can just the fact that a message is sent from A to B be used to
      suggest ssmething?  Remember, even if the messaging is secure
      an fiendish ssrt of spy can realize that since A is now sending
      a message that means A's office safe is not being watched, and
      as a result, may be open for an attack on it! Information may be
      garnered just from the fact of finding out that perssn A has
      sent a message to person Z, such as (1) they have something to
      talk about (hmm, what could it be?) or (2) that A's computer is
      on the network.

   3. A optical disk platter would be a very tempting target for a
      spy.  If one were stolen (the best theft is one were the owner
      does not realize that a theft has taken place, copying a disk
      surreptitiously fits this classification) it would likely be
      usable as the key source for months after the theft.  They need to
      balance the amount that can be stolen against the overhead of
      sending small amounts of random bits.

   4. Is a different selection of random bits always used?  How is
      the selection made?  Is the information of where to start
      kept in a secured file?  How much handshaking is done between
      the sender and recipient to ensure that both are using the
      correct selection?

   5. Because the network is not secure, an active tapper could
      interpose bad messages and delete good messages.  The messages
      might be secure by themselves but the transmission could be
      rendered useless.

   6. Systems that use the same key for encryption and decryption
      are susceptible to key distribution problems.  The random-key
      system falls into same-keyness.  Public/private keys can
      handle the key distribution problem nicely.

   7. Putting people into the encryption loop is never cheap.  Having
      a secure courier deliver the keys to the (just one?) recipient
      is expensive because the courier must be investigated and other
      security nonsense.

Bob Devine

In article <434@ethz.UUCP> wyle@ethz.UUCP writes:
>Random bits, generated from a radioactive source and calibrated counter
>are collected, and distributed by courier to remote sites.
>
>Messages are encoded via bit-wise exclusive-or, and transmitted via
>non-secure telecommunications.  The destinations use the courier-provided 
>random bits from the key tape to decode the messages.  Each bit is
>discarded after use.  Every few months, a new tape is sent by courier.

Certainly such a system, known generically as a "one-time pad"
after an analogous scheme used by spies, is theoretically
secure against cryptanalytic attack on the cipher stream.
Such a system used to be used for the Washington-Moscow hot
line teleprinters (for all I know it still is).  Although
security is in general a statistical matter (i.e. a measure of
the PROBABILITY of being able to correctly determine the plain
text under certain optimal assumptions), a one-time pad system
is absolutely unbreakable by statistical or algebraic analysis.

Any weaknesses in such a scheme have to lie elsewhere.  For
example, if the key bits are not really random (this CAN
happen; it happened in preparing the Rand Corp. table of a
million random digits!), then security is in theory
compromised; in practice, this is likely to be insufficient
for cracking the system, but nevertheless it is wise to put
a randomness monitor on the key stream and not use any long
run of key that tests out as "insufficiently random" (it
may be necessary to re-calibrate the equipment in this case).

Another line of attack is to collect discarded key tapes from
the dumpster and use them to read past messages.  (Would any
outfit be so stupid as to not permanently destroy the key tape?
It happens.)

Making a copy of the key while it's being "couriered" seems like
a useful tactic, if one can arrange it (this is not impossible).

Believe it or not, but sooner or later the encryptor will fail
and generate encrypted text that is easily readable (perhaps
entirely in clear!).  It is not considered "cheating" for a
cryptanalyst to use the resulting cheap decryption.

Easiest is to simply access the information before or after
the encrypted channel.

There are other possibilities, but generally a cipher system
of this type is very useful as part of a secure cryptosystem.
Its main drawback is the requirement for secure transmittal
of keys whose volume equals that of the message traffic.  In
cases where this is not an insurmountable obstacle, I highly
recommend one-time pad encryption.  (Other cases call for
different methods.  Warning: any system that has a key length
that is sufficiently shorter than the encrypted text is not
theoretically secure.  [How short is too short depends on
structural properties of the cryptosystem.]  Whether or not
it would be worth NSA's time and resources to break such a
system depends on the probable benefit of doing so.)

I think the optical disk might help make one-time pad systems
much more feasible than has historically been the case; then
the weakest point will be physical security for storage of the
disks.  (Note: no security is lost because of having to
transmit a key location identifier in the message header,
which is necessarily in the clear.)  I personally would LOVE
for there to be a practically unbreakable encryption system in
wide use; snoops do not deserve a break.

In article <132@vianet.UUCP> devine@vianet.UUCP (Bob Devine) writes:
>      message arrives in error, what happens?  A nasty person knowing
>      this information might be able to do a plain-text attack or 

This isn't possible for a true one-time pad system.  Crib dragging
and other favorite wedges into more traditional systems are useless
for this one.

>   2. Can just the fact that a message is sent from A to B be used to
>      suggest ssmething?

This sort of thing is the subject of a field known as "traffic
analysis", which I find rather interesting.  A good implementation
would have enough capacity for peak demands, then fill the channel
with random bits into which genuine messages would be inserted.  A
poor implementation would send messages only when there was a need
and would make their lengths obvious.  (The latter is hard to get
around, since there has to be some in-clear message header if only
for the purpose of maintaining synchronization; this argues for
a packet protocol of some sort.  Channel noise is not otherwise a
significant problem, though, since it can be dealt with by
conventional means.)

>   4. Is a different selection of random bits always used?  How is
>      the selection made?  Is the information of where to start
>      kept in a secured file?

It is essential that the bits not be re-used.  Many one-time pad
systems use different keys for different comlinks, to prevent
accidents.  Typically the message header tells the recipient which
key location to start at.  It is recommended that the used key be
destroyed as it is used.

>   5. Because the network is not secure, an active tapper could
>      interpose bad messages and delete good messages.

"Jamming" is a separate issue.  At least with this system it is
not possible to insert fake message whose decryption has any real
chance of appearing genuine, so long as there is a modest amount
of redundancy in the style of cleartext.  Truly low-redundancy
data should be given some redundancy before being encrypted.  This
and other indicators can be safely prefixed to the data, since it
isn't possible to detect them by analyzing the cipher stream.

>      a secure courier deliver the keys to the (just one?) recipient
>      is expensive because the courier must be investigated and other
>      security nonsense.

But this is just initial overhead; for an on-going operation the
high bandwidth of a courier airline bag full of optical disks is
actually very attractive from an economic standpoint.

In article <1338@navajo.STANFORD.EDU>, les@navajo.STANFORD.EDU (Lester Earnest) writes:
> The easiest way to compromise an exclusive-or cryptographic scheme with
> courier-distributed key is to bribe the courier and make a copy.  This
> cryptographic scheme is also very inefficient in that you have to
> transmit the same amount of data via courier as you do over the
> communication link.
> 

Now here's an interesting point.  The exact same amount of information has to
be transmitted as "key" information as will be transmitted as data.  Now since
the data is transmitted over an insecure channel, then the key data is the
valuable information.  So why not just use the secure courier for sending the
actual data?  I mean, if the courier system can be broken to get the key, the
data is suddenly rendered readable by anybody who cares.  So what is the
point of encryption at all in this case?

-- 
Steve Tate			UUCP: ..!{ihnp4,decvax}!duke!srt
				CSNET: srt@duke
				ARPA:  srt%duke@csnet-relay

      Realize that as an operational issue, key distribution is THE
problem in military cryptography.  One-time systems are useful when two
sites have a long-term, prearranged need to communicate.  Links between
embassies and their capitals are good candidates for one-time systems;
both ends are fixed sites, no switching is required, and secure storage
for non-trivial amounts of keying material is available at both ends.
But one embassy can't talk to another using the same keys used for the
link to headquarters.  Every link; worse, every potential link, that is,
every pair of stations that might ever want to communicate; requires
separate keying material, most of which will never be used.  All this
keying material must be generated under secure conditions, moved around
by secure couriers, stored in containers which make tampering evident,
and accounted for administratively.  Remember that the keying material
gets used up by traffic; send too much traffic and you run out of keying
material.  In some cases, you send junk traffic continously just to make
traffic analysis futile; this really uses up keying material.  The
Washington/Moscow hot line is in fact operated in that mode.
     In a military environment, this is too restrictive except in
special cases, such as links between major headquarters.  Military
units need to communicate in unanticipated directions on short notice.
In many cases, a considerable degradation in security is acceptable in
exchange for better communications.  Much military traffic is secret only
for a short time (the time and place of tomorrow's attack will, after all,
be known by the enemy once it starts), and a level of protection sufficient
to protect the traffic for hours or days may be sufficient.  Tactical
communications can never be completely secure; there is always the danger
of a station being captured with the keys intact. So excessive precautions
in the cryptosystem may be unjustified.
      Many of the real questions today are not "how can we make an
unbreakable cypher" but "how can we arrange things so as to minimize the
information compromised when a station is captured".  (In this context;
"captured" covers any means by which the opposition gains physical access
to keying material.)  One would like, for example, to have a system in
which capture of the current keying material does not allow you to read
old traffic.  That's the kind of feature you need at the level of, say,
the Army company.

      So one-time systems are useful, but not the entire answer. 

					John Nagle

In article <5580@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <434@ethz.UUCP> wyle@ethz.UUCP writes:
>>Messages are encoded via bit-wise exclusive-or, and transmitted via
>>non-secure telecommunications.  The destinations use the courier-provided 
>>random bits from the key tape to decode the messages.  Each bit is
>
>Believe it or not, but sooner or later the encryptor will fail
>and generate encrypted text that is easily readable (perhaps
>entirely in clear!).  It is not considered "cheating" for a
>cryptanalyst to use the resulting cheap decryption.

It is very easy for an exclusive-or to fail.  Too many zeroes and plain
text is the result.  Too many ones and it is inverted plain text.
-- 
Scot E. Wilcoxon   Minn Ed Comp Corp  {quest,dayton,meccts}!mecc!sewilco
(612)481-3507           sewilco@MECC.COM       ihnp4!meccts!mecc!sewilco
   
  "Who's that lurking over there?  Is that Merv Griffin?"

In article <682@rpics.RPI.EDU>, yerazuws@rpics.RPI.EDU (Crah) writes:
> In article <434@ethz.UUCP>, wyle@ethz.UUCP (Mitchell Wyle) writes:
 ...
 	
> Your big problem is going to be a known-plaintext spoofing attack.  
> If you can find out (or guess, because you've seen the plaintext of
> several other transmissions and KNOW they always start with the
> date, time, city of origin and sender's full name and title, in standard
> format)  then you can XOR your guess against the transmitted block
> and get back a good guess for the key FOR THAT BLOCK ONLY.  Given
> that key, you can spoof (fake) a transmission OF THE SAME LENGTH.
> You don't gain enough info to spoof the next block, however.  
 
  I think that this is even harder than this indicates.  A "good guess" is
not sufficient, because *any* guess will give a "key" for that block, and
there is no way to tell if the guess/key is correct.  So you have to have
the *exact* plaintext.

  The method described below can be thought of as having two purposes.  The
interior checksum does serve as a checksum, but more importantly it must be
a secret-algorithm checksum and serve as an unknowable/unguessable part of
the plaintext which the receiver can check.  Any other method of supply
such a field would serve equally well for verification.  E.g., just use the
next n bits of the one-time pad.  This is easily coordinated by the sender &
receiver, but not knowable (guessable at 2^n) by the interceptor/spoofer.

> To stop this, we had two checksums - an exterior one to verify that the block 
> was transmitted correctly, and an interior one which checked for tampering,
> spoofing, and known-plaintext attacks.  The probability of a known-plaintext
> (or chosen-plaintext ) spoof succeeding (because of the way the interior 
> checksum was generated) was one chance in 2^32.
  This only works if the interior checksum is generated by a method which the
interceptor can't duplicate.
 ...	
> Conclusion - The straight XOR system can be spoofed GIVEN that the content
> of a message can be guessed or is known beforehand.  That's the weakness.
> If the uncertanty of the message is high, and the uncertainty of the 
> keytape is complete, the system works.  (beware - an oversmplification
> exists in the above conclusion.  Read a text on information theory
> (such as Pierce's _Symbols, Signals, and Noise_ and you'll understand))
 ...
  Agreed.
> 	
> 	-Bill Yerazunis

--henry schaffer  n c state univ

Regarding one-time pads, wyle@ethz.UUCP writes:

>Any weaknesses in such a scheme have to lie elsewhere.  For
>example, if the key bits are not really random (this CAN
>happen; it happened in preparing the Rand Corp. table of a
>million random digits!), ...

Yup.  The "million random digits" book has been called Rand's most popular
work of fiction.

I heard rumors that somebody was able to do something with Cuban one-time
pads because the "random numbers" were generated by girls with typewriters
generating the random :-) digits at their keyboards.

I think I'd better put a disclaimer on this one, although I usually don't:
This is solely my personal opinion, and not necessarily that of my employer,
the Rand Corporation.
-- 
	Jim Gillogly
	{hplabs, ihnp4}!sdcrdcf!randvax!jim
	jim@rand-unix.arpa

In article <9112@duke.duke.UUCP> srt@duke.UUCP (Stephen R. Tate) writes:
>Now here's an interesting point.  The exact same amount of information has to
>be transmitted as "key" information as will be transmitted as data.  Now since
>the data is transmitted over an insecure channel, then the key data is the
>valuable information.  So why not just use the secure courier for sending the
>actual data?  I mean, if the courier system can be broken to get the key, the
>data is suddenly rendered readable by anybody who cares.  So what is the
>point of encryption at all in this case?

That's the main problem with one time pads.  Their only real use is that
you can use a slow courier ahead of time, and then use an insecure but
fast channel (such as radio) at a later time.

		-ed falk, sun microsystems
		sun!falk, falk@sun.com
terrorist, cryptography, DES, drugs, cipher, secret, decode, NSA, CIA, NRO.

In article <875@mecc.MECC.COM> sewilco@mecc.UUCP (Scot E. Wilcoxon) writes:
>It is very easy for an exclusive-or to fail.  Too many zeroes and plain
>text is the result.  Too many ones and it is inverted plain text.

So what?  All you get is small fragments of recognizable text.  For all
the spy who sees it knows, it could have been something else that got
changed *into* something readable.  If your random number is any good
at all, very long strings of zeros and ones won't appear.  For instance,
for twenty characters in a row to come out unencrypted (assuming you're
using 7-bit ascii) would require 140 zeros in a row to come out of the
random number generator.  This happens once every
199,113,796,415,000,000,000,000,000,000,000,000,000,000 characters of
output.  Note that the phrase "Nuke Moskow tomorrow", complete with
correct spelling and capitalization occurs in encrypted text
(regardless of what the original text said) with *exactly* the same
frequency as a 20-character burst of unencrypted text.

	-ed falk, sun microsystems
(don't need no nsa lineater for this one)

>
>It is very easy for an exclusive-or to fail.  Too many zeroes and plain
>text is the result.  Too many ones and it is inverted plain text.
>-- 
>Scot E. Wilcoxon   Minn Ed Comp Corp  {quest,dayton,meccts}!mecc!sewilco
>(612)481-3507           sewilco@MECC.COM       ihnp4!meccts!mecc!sewilco
>   


All of these discussions of the failure of exclusive-or depend upon the
pad of random bits to not be random.  If the bits are "sufficiently"
random, the likelihood that a message of length 20 comes through with
no errors is exactly the same as the string "I killed John Lennon".
Also, the chance that the transmitted message differs from the real
message by K bits is exactly the same as the chance as the transmission
differing from "I killed John Lennon" by K bits.  The only problem
arises when the decoding of the known header gives the code breaker
enough information to predict the bits of the "random" pad.

Eddie Grove

P.S.  I did not kill John Lennon.

In article <9112@duke.duke.UUCP> srt@duke.UUCP (Stephen R. Tate) writes:
>
> Now since the data is transmitted over an insecure channel, then
> the key data is the valuable information.  So why not just use
> the secure courier for sending the actual data?

Because the key is only valuable if you use it to send a message.

If you send the message itself via courier, then an enemy simply has
to steal the message to get the information.  They don't have to be
subtle.

If you only send the key, then not only must the enemy steal the key,
but they must do it in such a way that you will not suspect that they
got it.  If you do suspect, you simply don't use it, and they get nothing.
They have to be much more subtle to get your message this way.
-- 
Religion: just say "no"

Tim Smith       USENET: sdcrdcf!ism780c!tim   Compuserve: 72257,3706
                Delphi or GEnie: mnementh

Yes, the quantity of key is the same as the message, and yes, the
key channel must be by definition secure, but no, the key channel is
not an adequate substitute for the encrypted message channel. You 
transmit the key early, in *anticipation* of a time when you will have
a secret message to transmit in timely fashion. If you knew the message
from the beginning, you could courier it instead of the key, but then 
you wouldn't need an encrypted telcom link. Even if your message is as
simple as "read the message in the blue envelope which the courier
brought and act on it, while ignoring the message in the red envelope",
you need (1 bit of) securely transmitted key.

Doug Maisel

In article <9112@duke.duke.UUCP>, srt@duke.UUCP (Stephen R. Tate) writes:
> In article <1338@navajo.STANFORD.EDU>, les@navajo.STANFORD.EDU (Lester Earnest) writes:
> > The easiest way to compromise an exclusive-or cryptographic scheme with
> > courier-distributed key is to bribe the courier and make a copy.  This
> > cryptographic scheme is also very inefficient in that you have to
> > transmit the same amount of data via courier as you do over the
> > communication link.
> > 
> 
> Now here's an interesting point.  The exact same amount of information has to
> be transmitted as "key" information as will be transmitted as data.  Now since
> the data is transmitted over an insecure channel, then the key data is the
> valuable information.  So why not just use the secure courier for sending the
> actual data?  I mean, if the courier system can be broken to get the key, the
> data is suddenly rendered readable by anybody who cares.  So what is the

OK, let's assume that we manage to knock out the courier, copy his
key tape, and let the courier wake up without his having noticed anything
happened.  Well, I was sneaky and put the key tape in a plastic bag, and
the bag had an atmosphere that had a little too high Ar40/Ar42 ratio.  
(or some other truly sneaky way to tell that the tape had been possibly
compromised, like a tiny trace of cocaine four hundred feet in on the oxide,
or some other chemical which we can detect in nanogram amounts if we only
know to look.)
	
Now I know someone is attacking my system, and that the tape I now have 
is probably in their hands as well... Fine.  I can send messages over that
channel which are DISinformation, to mislead the enemy.  Meanwhile, I get
another tape by some other courier using a different transport, etc. and
use that for my real data needs.
	
If I'm not interested in active disinformation, I can just not use that
compromised tape and all the enemy has found are a lot of random bits- 
which he can subject to statistical analysis.  If my random-number 
generator was good, he gets nothing but a huge bill for cpu-hours.  
This tells him nothing but that he has to bribe/knock out a courier;
which he knew in the first place.
	
	-Bill Yerazunis

In article <2611@ecsvax.UUCP>, hes@ecsvax.UUCP (Henry Schaffer) writes:
> In article <682@rpics.RPI.EDU>, yerazuws@rpics.RPI.EDU (Crah) writes:
> > In article <434@ethz.UUCP>, wyle@ethz.UUCP (Mitchell Wyle) writes:
> >  ...  	
> > Your big problem is going to be a known-plaintext spoofing attack.  
> > If you can find out (or guess, because you've seen the plaintext of
> > several other transmissions and KNOW they always start with the
> > date, time, city of origin and sender's full name and title, in standard
> > format)...
>  
>   I think that this is even harder than this indicates.  A "good guess" is
> not sufficient, because *any* guess will give a "key" for that block, and
> there is no way to tell if the guess/key is correct.  So you have to have
> the *exact* plaintext.
> 

What I mean by a good guess is one that gives you a high probability of 
being exactly correct- hence your spoof message is decrypted correctly 
and believed authentic.

> > spoofing, and known-plaintext attacks.  The probability of a known-plaintext
> > (or chosen-plaintext ) spoof succeeding (because of the way the interior 
> > checksum was generated) was one chance in 2^32.
>   This only works if the interior checksum is generated by a method which the
> interceptor can't duplicate.


Exactly.  For example, use a pair of 32-bit words from the keytape.  One word
specifies the initial condition of the CRC register, and the second is 
XORed into the CRC output just before concatenation of that register 
onto the text to be transmitted.  Given either of the 32-bit words, 
I can calculate what the other should have been to give the observed 
cyphertext stream- but this still only cuts me down to an ensemble of 
2^32 pairs of possible words, only one of which will give the "right" 
cyphertext for all plaintext messages, the other 2^32 - 1 will work 
for the specific known plaintext but will (with high probability, given
a good CRC) fail on other plaintexts.  So, the algorithm can be public
and only the key tape needs security.  Knowing two block's wordpairs 
doesn't help, because they were interior-checked by two different pairs
of words.

> >      .........................  Read a text on information theory
> > (such as Pierce's _Symbols, Signals, and Noise_ and you'll understand))
>  ...
>   Agreed.
 
Definitely.  A good book is something truly worthwhile.

> > 	
> > 	-Bill Yerazunis
> 
> --henry schaffer  n c state univ

	-Bill Yerazunis
 
	"NSA food?  Here?  Why bother?"

In article <9112@duke.duke.UUCP> srt@duke.UUCP (Stephen R. Tate) writes:
>In article <1338@navajo.STANFORD.EDU>, les@navajo.STANFORD.EDU (Lester Earnest) writes:
>> The easiest way to compromise an exclusive-or cryptographic scheme with
>> courier-distributed key is to bribe the courier and make a copy.  
>
>Now here's an interesting point.  The exact same amount of information has to
>be transmitted as "key" information as will be transmitted as data.  Now since
>the data is transmitted over an insecure channel, then the key data is the
>valuable information.  So why not just use the secure courier for sending the
>actual data?  

The key channel must be secure but may be very slow (e.g. a sealed packet in
a hand-carried diplomatic bag once a month) but the messages are timely over
an insecure channel (e.g. radio transmissions).    This is the procedure
used by foreign embassies, for example.

Also, in information theory "value" does not necessarily equal "bit count"!








[sorry about the blank lines but first time inews rejected it because
on grounds that I had not added enough lines.   What a dumb 'feature'.]

-- 
Regards,
        David Wright          STL, London Road, Harlow, Essex  CM17 9NA, U.K.
dww@stl.stc.co.uk <or> ...seismo!mcvax!ukc!stl!dww <or> PSI%234237100122::DWW

For those of us new to this group, what is this "NSA line eater?"

thanks,

	James

In article <12414@sun.uucp> falk@sun.UUCP (Ed Falk) writes:
>In article <9112@duke.duke.UUCP> srt@duke.UUCP (Stephen R. Tate) writes:
>>Now here's an interesting point.  The exact same amount of information has to
>>be transmitted as "key" information as will be transmitted as data. ...  So
>>what is the point of encryption at all in this case?
>
>That's the main problem with one time pads.  Their only real use is that
>you can use a slow courier ahead of time, and then use an insecure but
>fast channel (such as radio) at a later time.

A theoretical case where they would also be useful would be where you have a
secure channel from point A to point B, but no secure channel from point B
to point A.  Then you send the key information by the secure channel, and
use it for transmissions back to point A.  I can't think of any actual
instances where this would apply, though.

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108

In article <875@mecc.MECC.COM> sewilco@mecc.UUCP (Scot E. Wilcoxon) writes:
>It is very easy for an exclusive-or to fail.  Too many zeroes and plain
>text is the result.  Too many ones and it is inverted plain text.

That wasn't my point at all, and is a common misconception.
If the encryptor is functioning properly, there will have to
eventually be isolated stretches of 0s in the key that produce
plaintext in the cipher stream, but there is no way for the
cryptanalyst to distinguish these occurrences from other
apparent plaintext sequences that are purely fortuitous.

My actual point was that hardware FAILS from time to time.
Shift registers stop shifting, or-ers lose their keys, etc.

In article <5580@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>Another line of attack is to collect discarded key tapes from
>the dumpster and use them to read past messages.  (Would any
>outfit be so stupid as to not permanently destroy the key tape?
>It happens.)

Yes, the United States Navy is this stupid.  My understanding -- the
newspapers all claimed it was 'classified'  -- is that the Walker spy
ring gave the Soviets the old keys.  These were, of course, useless
for future messages but did enable them to break recorded encrypted
messages.

(Apparently our forces have an electronic equivalent to many
one-time-pads, and know which one to use next.)

andy

In article <924@cartan.Berkeley.EDU> lazarus@brahms.Berkeley.EDU (Andrew J Lazarus) writes:
>>the dumpster and use them to read past messages.  (Would any
>>outfit be so stupid as to not permanently destroy the key tape?
>
>Yes, the United States Navy is this stupid.  My understanding -- the
>newspapers all claimed it was 'classified'  -- is that the Walker spy
>ring gave the Soviets the old keys.  These were, of course, useless

There was an article in the paper a while ago about either the Air Force
or Navy, I can't remember.  Apparently they had several hundred used tapes
they no longer needed.  They sold them at public auction, complete with
classified (unencrypted) data.

				--robert

--
CSNET:   robert%jimi.cs.unlv.edu@relay.cs.net
UUCP:    {akgua,ihnp4,mirror,sdcrdcf}!otto!jimi!robert
         seismo!unrvax!tahoe!jimi!robert