Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!mtuxo!mtunh!mtung!mtunf!ariel!vax135!cornell!uw-beaver!tektronix!hplabs!pesnta!greipa!decwrl!decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn )
Newsgroups: net.crypt
Subject: Re: Encryption using compression
Message-ID: <11379@brl-tgr.ARPA>
Date: Thu, 4-Jul-85 20:19:52 EDT
Article-I.D.: brl-tgr.11379
Posted: Thu Jul  4 20:19:52 1985
Date-Received: Thu, 11-Jul-85 05:04:37 EDT
References: <5992@duke.UUCP>
Distribution: net
Organization: Ballistic Research Lab
Lines: 36

> If I were to use a simple substitution cypher with an
> arbitrary premutation of bytes on the output of a good compression
> program how could the resulting file be attacked?

The general idea of removing redundancy to make cryptanalysis
harder is a good one.  However, most data compression schemes
amount to fairly simple encryptors (e.g. each 8-bit input
chunk might be taken to a constant output chunk of width from
2 to 8 bits, with a prepended mapping table).  Methods for
dealing with this form of variable-length encryption exist and
could be re-invented if necessary.

The weak point of the proposed scheme seems to be in conveying
the permutation and compression keys; if the permutation is not
changed for each message, then it can be broken through by a
"stacking" scheme.  In any case, you have to expect that any
constant elements of an encryption scheme are potentially
known to the cryptanalyst.  So, if you enclose permutation
information with the ciphertext, it will be a simple matter for
the analyst to extract it and untranspose the text the same way
the intended recipient would.  Then he just has to work on the
compression scheme through an overlaid simple substitution.
Although he won't be able to apply frequency distribution tests
to strip the substitution, these are not usually heavily used
in breaking simple substitution anyhow.  If I had to analyze such
a message, I'd probably try to break out the compression table
at this point and analyze possible substitutions against a
"crib" assumed to be present in the message (like, "From: ..."
at the front of the plaintext).  It should be possible to rule
out all but a handful of possible substitutions this way.
Then the rest of the task is just extending the meaning of the
plaintext a bit at a time while checking for consistency against
what is already known.

In other words, it would be a lot of work but most cryptanalysis
is like that.