Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!cbosgd!ihnp4!houxm!hjuxa!petsd!joe
From: joe@petsd.UUCP (Joe Orost)
Newsgroups: net.crypt
Subject: Re: randomly adding bits/bytes (compressing text before encryption)
Message-ID: <806@petsd.UUCP>
Date: Fri, 15-Aug-86 00:05:31 EDT
Article-I.D.: petsd.806
Posted: Fri Aug 15 00:05:31 1986
Date-Received: Sat, 16-Aug-86 07:34:09 EDT
References: <8608042018.AA04376@ucbjade.Berkeley.Edu> <7024@utzoo.UUCP>
Reply-To: joe@petsd.UUCP (Joseph M. Orost)
Organization: Perkin-Elmer DSG, Tinton Falls, N.J.
Lines: 35

In article <7024@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>> ... Using compress(1) before using crypt(1) or
>> a DES-based system is an excellent idea, as long as the person at the
>> other ends knows to uncompress(1) the message afterwards.
>
>Um, actually, there may be a serious problem here:  compress(1)ed files
>start with stereotyped header information that could offer a cryptanalyst
>the opportunity for a known-plaintext attack.  Something needs to be done
>about that before generally recommending this approach (which is a good
>one otherwise).

How true indeed!!!  However, there is a (undocumented) flag to get around
this problem.  It was put in for compatibility with a very old version of
compress, but you just found a good use for it:

	-n	Suppress 3-byte header on the compressed file

It must be specified to BOTH compress(1) and uncompress(1).

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.

				regards,
				joe

--

 Full-Name:  Joseph M. Orost
 UUCP:       ihnp4!vax135!petsd!joe
 ARPA:	     vax135!petsd!joe@BERKELEY
 Phone:      (201) 758-7284
 Location:   40 19'49" N / 74 04'37" W
 US Mail:    MS 313; Concurrent Computer Corporation; 106 Apple St
             Tinton Falls, NJ 07724