wyle@ethz.UUCP (Mitchell Wyle) (01/23/87)
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? -- M i t c h e l l F W y l e EEEEE TTTTTT H H Eidgenoessische | wyle%ifi.ethz.chunet@csnet-relay E T H H Technische Hochschule | wyle@ethz.uucp EEEE T HHHHH Zuerich | ...!cernvax!ethz!wyle E T H H Institut fuer Informatik| Telephone: 011 41 1 256 5235 EEEEE T H H 8092 Zuerich, Switzerland| "Ignore alien orders"
lubich@ethz.UUCP (Hannes Lubich) (01/23/87)
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 ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
yerazuws@rpics.RPI.EDU (Crah) (01/24/87)
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 "
les@navajo.UUCP (01/25/87)
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.
levy@ttrdc.UUCP (01/25/87)
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
falk@peregrine.UUCP (01/25/87)
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.)
stuart@bms-at.UUCP (01/27/87)
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>
devine@vianet.UUCP (01/27/87)
[ 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
gwyn@brl-smoke.UUCP (01/28/87)
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.
gwyn@brl-smoke.UUCP (01/28/87)
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.
srt@duke.UUCP (01/28/87)
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
jbn@glacier.UUCP (01/29/87)
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
sewilco@mecc.UUCP (01/29/87)
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?"
hes@ecsvax.UUCP (01/29/87)
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
jim@randvax.UUCP (01/30/87)
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
falk@peregrine.UUCP (01/30/87)
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.
falk@peregrine.UUCP (01/30/87)
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)
grove@ernie.Berkeley.EDU.UUCP (01/30/87)
> >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.
tim@ism780c.UUCP (01/31/87)
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
newton2@topaz.berkeley.edu.UUCP (01/31/87)
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
yerazuws@rpics.RPI.EDU (Crah) (02/03/87)
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
yerazuws@rpics.RPI.EDU (Crah) (02/03/87)
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?"
dww@stl.stc.co.uk (David Wright) (02/04/87)
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
gwyn@brl-smoke.UUCP (02/08/87)
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.
lazarus@brahms.Berkeley.EDU.UUCP (02/11/87)
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