Article View: sci.crypt
Article #3367Re: bitwise exclusive-or
From: hes
Date: Thu, 29 Jan 1987 15:23
Date: Thu, 29 Jan 1987 15:23
46 lines
3069 bytes
3069 bytes
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
Technical Details
Message-ID:
<2611@ecsvax.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!decvax!mcnc!ecsvax!hesReferences:
<434@ethz.UUCP> <682@rpics.RPI.EDU>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!decvax!mcnc!ecsvax!hes From: hes@ecsvax.UUCP Newsgroups: sci.crypt Subject: Re: bitwise exclusive-or Message-ID: <2611@ecsvax.UUCP> Date: Thu, 29-Jan-87 10:23:20 EST Article-I.D.: ecsvax.2611 Posted: Thu Jan 29 10:23:20 1987 Date-Received: Sat, 31-Jan-87 07:23:00 EST References: <434@ethz.UUCP> <682@rpics.RPI.EDU> Organization: NC State Univ. Lines: 46 Keywords: xor Summary: one time pads work well - key recovery is hard