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