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.