Re: confusing terminology

Rick van Rein <rick@openfortress.nl> Tue, 08 February 2005 09:29 UTC

Date: Tue, 08 Feb 2005 10:00:20 +0100
From: Rick van Rein <rick@openfortress.nl>
Subject: Re: confusing terminology
In-reply-to: <42085A7D.1000704@algroup.co.uk>
To: Ben Laurie <ben@algroup.co.uk>
Message-id: <20050208090020.GB33720@phantom.vanrein.org>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Content-disposition: inline
User-Agent: Mutt/1.4.2.1i
References: <20050207232427.GA37525@phantom.vanrein.org> <42085A7D.1000704@algroup.co.uk>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ben, others,

> >As for the "added side-effect" (which states the same thing doubly twice) I
> >see a cryptographic advantage in compression that should go here :- by
> >compressing a message, the entropy of the data that is encrypted is made
> >as high as possible.
> 
> Entropy is not altered by (lossless) compression.

Perhaps I wasn't clear enough.  The entropy in the total document is not
increased, but the entropy per encrypted block is.

Plain English text is good for about 1 bit of entropy per character/byte;
after compression, the total size is less, certainly for plain English
text.  This means that the same information is stored in less bytes, so
the entropy per byte (or per block of bytes) has risen.

It is advantageous to a cryptanalist to know that the input to an
encryption algorithm is plain English text, because it means that
possible variations of the input are greatly reduced.  Compression
makes that assumption go wrong.

For this reason, I would never, ever encrypt without compressing first.
This is the cryptographic advise I would like to see in the indicated place.

Cheers,
 -Rick