Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site duke.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!duke!bet
From: bet@duke.UUCP (Bennett E. Todd III)
Newsgroups: net.crypt
Subject: Re: Encryption using compression
Message-ID: <5993@duke.UUCP>
Date: Fri, 5-Jul-85 19:41:01 EDT
Article-I.D.: duke.5993
Posted: Fri Jul  5 19:41:01 1985
Date-Received: Mon, 8-Jul-85 01:32:30 EDT
References: <5992@duke.UUCP> <11379@brl-tgr.ARPA>
Reply-To: bet@ecsvax.UUCP (Bennett E. Todd III)
Distribution: net
Organization: Duke University Computation Center
Lines: 37


Assuming of course that the algorithm is public knowledge, then in
any encryption scheme not based on a "trapdoor" (and all of those I
am aware of are computationally abusive to the *users* of the system
by the time they are intricate enough to be secure), the key must be
communicated separately from the message, and securely. If I were to
take the output of the LZ-compression program compress(1) which has
been posted to the net recently (no frequency tables), and permute
the bytes in it with a systematic shuffle, and then maybe apply a
substitution throughout to ward off any brute force efforts, then I
would consider the shuffle and substitution to compose the key -- I
visit the friend in question, put on some Police real loud, and
whisper to him/her the shuffle that I will use.  Has some part of
this procedure violated the current rules about what constitutes an
encryption system worthy of note? I realize I haven't addressed the
key distribution problem, but then if I meet my friend *once*, then I
can include a shuffle definition and substitution in the plaintext,
and the friend will know to use them to decrypt the *next* message.
This all seems far more simple-minded than the intricate
number-theoretical approaches currently being used in cryptology, and
for the life of me I can't see what even the NSA and a flock of Crays
could do about it.

Think about it: I give you a binary file, and tell you that if you
shuffle the bytes in the file in some fashion, and apply some
substitution to them, then you can run the result through compress(1)
and read the document. The transposition and substitution (neither
adequate to ward of determined attack alone) are sitting on top of a
uniform distribution of bytes, +/- some epsilon relatively independent
of the source text. Given a permutation chosen to keep bytes within
say 32K chunks, none of the operations involved is particularly slow.
Am I missing something? (besides any backgound whatsoever in
cryptology, thanks:-).

-Bennett-- 

Bennett Todd -- Duke Computation Center, Durham, NC 27706 -- +1 919 684 3695
UUCP - bet@ecsvax, bet@duke, ...{decvax,ihnp4,akgua}!mcnc!ecsvax!bet