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