Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!jvnca!njitsc1!argus!ken
From: ken@argus.UUCP (Kenneth Ng)
Newsgroups: sci.crypt
Subject: Re: Encryption of Hoffman coded text
Message-ID: <1001@argus.UUCP>
Date: Sun, 16-Aug-87 16:58:25 EDT
Article-I.D.: argus.1001
Posted: Sun Aug 16 16:58:25 1987
Date-Received: Sun, 16-Aug-87 23:08:26 EDT
References: <3515@cit-vax.Caltech.Edu> <1290004@hpcvlo.HP.COM>
Organization: NJ Instit. of Tech: TEIES Project
Lines: 37

In article <1290004@hpcvlo.HP.COM>, john@hpcvlo.HP.COM (John Eaton) writes:
> > It seems to me that Hoffman coding makes the plaintext look more 'random'
> > and, so, less amenable to statistical attack.  Is this so?
> ----------
> I suspect that most compression techniques are not very effective
> when used on an already compressed file. If so you simply compress the
> decrypted bytes and only examine those keys that don't save a lot of bytes.
> John Eaton
> !hplabs!hp-pcd!john

A 'perfectly' compressed file cannot be compressed further because the
objective of compression is to spread the distribution of the byte
sequences uniformally throughout the medium.  Obviously once you
achieve uniform distribution, no further compression is possible.

I believe the original query was to first use a compression technique,
and then use an encryption scheme to encrypt the compressed material.
This technique makes even a simple substitution code more difficult to
break because the statistical data used break a substitution code is
partly hidden due to the homogenizing effect of text compression.
I believe I made this same query last year, only I used Lempal Ziv
data compression instead.  The responses (if I remember them correctly)
were to watch out for common header leaders in the file.  Also
someone noted that it might be possible to reconstruct a Lempal Ziv
compression by noting that the front of the file will contain
fewer possible combinations than later on in the file.  This scheme
could be made more difficult by first encoding a 'dummy' header in
front of the real message, and then stripping off the compression
done for the dummy header.  This of course assumes that the header
can be known to the proper people.  

Did I get everything right?

Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey  07102
uucp: rutgers!andromeda!argus!ken
uucp !ihnp4!allegra!bellcore!argus!ken *** NOT ken@bellcore.uucp ***
bitnet(prefered) ken@orion.bitnet