Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!think!nike!cit-vax!elroy!smeagol!usc-oberon!sdcrdcf!ucla-cs!caip!meccts!mecc!sewilco
From: sewilco@mecc.UUCP (Scot E. Wilcoxon)
Newsgroups: net.crypt
Subject: Re: randomly adding bits/bytes (compressing text before encryption)
Message-ID: <639@curly.ucla-cs.ARPA>
Date: Tue, 19-Aug-86 18:26:00 EDT
Article-I.D.: curly.639
Posted: Tue Aug 19 18:26:00 1986
Date-Received: Fri, 22-Aug-86 22:06:18 EDT
References: <8608042018.AA04376@ucbjade.Berkeley.Edu> <7024@utzoo.UUCP> <806@petsd.UUCP>
Reply-To: sewilco@mecc.UUCP (Scot E. Wilcoxon)
Organization: MN Ed Comp Corp, St Paul, MN
Lines: 17
Summary: But compress tends to have plaintext at the beginning...

In article <806@petsd.UUCP> joe@petsd.UUCP (Joseph M. Orost) writes:
>In article <7024@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>>> ... Using compress(1) before using crypt(1) or...
>Compressed data is very good for encryption, because it contains almost no
>redundancy, and no constant data (with the header gone).  Unlike Huffman
>coding, there is no compression table in the data at all.

The compress program's output is more compressed as it goes along, so that
the beginning is in practically plaintext.  I think this is what an earlier
poster meant when referring to a header weakness, not just the 3-byte header.
(Other compression programs tend to have large headers with compression
tables in them.)
-- 
Scot E. Wilcoxon    Minn Ed Comp Corp  {quest,dicome,meccts}!mecc!sewilco
45 03 N  93 08 W (612)481-3507 {{caip!meccts},ihnp4,philabs}!mecc!sewilco
	Laws are society's common sense, recorded for the stupid.
	The alert question everything anyway.