Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.crypt
Subject: Re: randomly adding bits/bytes
Message-ID: <7035@utzoo.UUCP>
Date: Tue, 12-Aug-86 18:46:04 EDT
Article-I.D.: utzoo.7035
Posted: Tue Aug 12 18:46:04 1986
Date-Received: Tue, 12-Aug-86 18:46:04 EDT
References: <8608042018.AA04376@ucbjade.Berkeley.Edu>, <437@argus.UUCP>
Organization: U of Toronto Zoology
Lines: 41

> ...The scheme is using Lempal Ziv
> compression to compress the text, resulting in essentially random
> information, with redundent text removed.  The output of that is then
> fed through a 256 byte translate table.  Thus both sides must have only
> the translate table to communicate back and forth.  Does anyone know
> how resistent to cracking this method would be?  ...

It depends on how private your L-Z compressor is.  The translate table
is a monoalphabetic substitution; by itself, any bright 8th-grader could
break it.  Your only hope for security is to make sure that nobody knows
the details of the format that your compressor is producing.  Using the
standard "compress" utility is a very bad idea in this context.  You want
to avoid programs which put magic numbers, fixed-format headers, or
compression tables of a standardized form at the beginning (end, etc.) of
the compressed data.  I don't know enough about the details of L-Z to be
sure if such things can be avoided, but I have my doubts.

A good data-compression algorithm is a fine preliminary to encryption,
since it fouls up the frequency information royally.  But by itself,
DATA COMPRESSION IS NOT ENCRYPTION.  Your security still depends mainly
on the encryption step that follows.  In particular, your security
depends *entirely* on the encryption step if you make the standard
assumption that a would-be snooper knows your basic algorithms.  I am
not an expert in this area, but even from my limited knowledge, I would
emphatically recommend that you use something less flimsy than a simple
substitution as your encryption scheme.  I am not kidding when I say
that a bright 8th-grader could break that.

One idea you might consider would be your proposal as described,
followed by the Unix crypt(1) command.  Crypt(1) by itself is fatally
insecure, and methods for breaking it have been published... but they
aren't trivial, the programs for doing them aren't widely available, and
putting translated compressed data rather than ASCII plaintext in underneath
should make life a lot harder for the nosy.  The compression removes the
frequency information and the translation would obscure compression's
headers somewhat.  Don't forget to change keys often, and to change BOTH
the translation table and the crypt(1) key.  (Also, if you are protecting
something important, get expert advice [not just mine] first.)
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry