symmetric encryption broken

Michael H. Warfield mhw at wittsend.com
Fri Mar 9 22:35:01 CET 2001


On Fri, Mar 09, 2001 at 04:26:41PM -0500, Michael H. Warfield wrote:
> On Fri, Mar 09, 2001 at 10:13:01PM +0100, Matthias Urlichs wrote:
> > Hi,
> 
> > Michael H. Warfield:
> > > 	Huh...  Wait a minute.  You're encrypting it once and then
> > > encrypting it a second time.  What are you trying to accomplish here?
> 
> > Some ciphers are symmetric. If you DES-encrypt something, and then "encrypt"
> > the ciphertext again, you magically get the plaintext back.

> 	Some are.  Damn few.  DES definitely NOT.

> 	Encrypt DES != Decrypt DES...  Take a good look at Bruce Schneier's
> Applied cryptography.  In particular, look at the section on 3DES where
> he describes the EDE mode (Encrypt Decrypt Encrypt mode).  When all three
> keys are equal (K1 = K2 = K3 = K) you have 56 bit DES compatibility mode
> because the "D" reverses the first "E".  If the algorithm were symetrical
> there would be no need for that distinction.  Classical 112 bit 3DES has
> K1 = K3 while 168 bit 3DES has all three keys different.

> 	What's more, there are several OTHER things going on here.  One,
> he is ascii armoring the file.  Even if he used the NULL cypher (re IPSec
> and the exportable Caeser Cypher :-) ) he would have still ascii armored
> it twice.  As it so happens, he passes it through the encryption algorithm,
> then ascii armors it (the -a option) to generate a new text file.  The
> second encrypt is going to encrypt the ascii armored output of the
> first encryption.  Armoring twice is certainly not going to be symetrical!

> > The same thing works with any cipher algorithm which computes a secure
> > hash and XORs it with the plaintext. (You could use MD5 as a cipher that
> > way.)

> 	A XOR stream cypher such as RC4 would work like this (and is one
> of the primary reasons why WEP encryption for 802.11 is so severely
> BROKEN) but DES is a BLOCK cypher.  It doesn't work that way.

	Damn...  Forgot my other point (that also plays back into the
dain bramaged encryption in 802.11).  Don't forget about initialization
vectors and seed padding, either.  These will not (or should not - another
screw-up in 802.11 WEP) be the same each time you encrypt something.  The
IV should give you a different cypherstream each time.  The other end
takes the IV which you hand it to decrypt.  If it things it's encrypting
again, it generates a new IV and a new cyphersteam to encrypt the data
you give it (the old encrypted data and the old IV).  Still doesn't
reverse.

> > -- 
> > Matthias Urlichs     |     noris network AG     |     http://smurf.noris.de/

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw at WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!




More information about the Gnupg-devel mailing list