Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site randvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!mtuxo!mtunh!mtung!mtunf!ariel!vax135!cornell!uw-beaver!tektronix!hplabs!sdcrdcf!randvax!jim
From: jim@randvax.UUCP (Jim Gillogly)
Newsgroups: net.crypt
Subject: Re: Encryption using compression
Message-ID: <2591@randvax.UUCP>
Date: Wed, 10-Jul-85 13:29:35 EDT
Article-I.D.: randvax.2591
Posted: Wed Jul 10 13:29:35 1985
Date-Received: Wed, 17-Jul-85 07:20:59 EDT
References: <5992@duke.UUCP> <11379@brl-tgr.ARPA> <5993@duke.UUCP> <78@oberon.UUCP>
Reply-To: jim@rand-unix.UUCP (Jim Gillogly)
Distribution: net
Organization: Banzai Institute
Lines: 35

In article <78@oberon.UUCP> tli@oberon.UUCP (Tony Li) writes:
>The problem with your beautiful theory is that you haven't changed the
>frequency of the characters in your text.  By running compress on the
>plaintext, you've simply inserted a substitution cipher before your shuffle
>cipher.  Once the natural language of the plaintext becomes known, it should
>quickly become obvious to the cryptographer that your character frequencies
>are incorrect.  This leads immediately to the idea of a substitution.

Doug Gwyn and I posted suggestions on how to attack this kind of cipher, but
the solution here isn't as easy as he makes it look.  Compress does "only"
insert a simple substitution before the transposition, but it is a
variable-length substitution.  Therefore (if the permutation is "random",
as the poster specified) the permuted ciphertext elements contain PIECES of
letters, not permuted letters themselves.  As the original poster pointed
out, the distribution of a compressed file will look very even on a byte-wise
frequency count -- the individual letter frequencies are suppressed.

Doug suggested that it would be difficult to pass the information about which
transposition to use, and correctly points out that if the transposition is
fixed it is useless.  It seems to me that the problem is no more difficult
than the usual key-exchange problem: whenever two correspondants need to
communicate securely they need to find a common key.  Several methods have
been published for doing this (fairly) securely.  Depending on how paranoid
you are you can phone it in...

Given the keyword, use it to initialize a random number generator (not
a linear congruential one, please!), which you then use for a stream of
pseudo-random bytes.  Then it's off to Knuth vol. 3 to find out how to
generate a random permutation (exchange each element of your block in
turn with some randomly selected element of the block).  The recipient
uses the inverse permutation and you're in business.
-- 
	Jim Gillogly
	{decvax, vortex}!randvax!jim
	jim@rand-unix.arpa