Subject: confusing terminology

From: Rick van Rein <[email-masked]>
Date: Tue, 08 Feb 2005 00:24:27 +0100

Hello,

I entered this list just recently, sorry about that.
I am wading through the spec bit by bit, hoping to add improvements.

After reading sections 1 and 2 I have seen a lot of confusing names,
often covering the same thing and sometimes used with different meaning.
This does not appeal to me as good specification habits I fear.

>> Message, data file, object, session

These terms are used in a rotary scheme, but the reader must assume they
mean the same thing, and not something slightly different.  The original
thought of OpenPGP seems to have been message formats as sent by email,
but then PGP disk encryption came and the terms had to be altered.

Can be agree on one term for "the stuff that is PGP-ified" perhaps?
I think "OpenPGP data" will be fine, in contrast to "readable data".

>> OpenPGP: spec or implementation?

Section 1.1 teaches us that "OpenPGP" is the name of a definition
(or specification?) but the list items in section 2.1 use it to indicate
a program.  I propose to change "OpenPGP" to "OpenPGP implemetation"
in these list items.

Section 2.0 introduces a self-contradicting loop, by stating that OpenPGP
(the document) does a few things that are beyond the scope of this
document.

A finer note on 1.1 -> I don't think definitions are formalized, instead I
think specifications are described or formulated.  Am I going too far?

The subset from 2.5 is sufficiently clear -- but it would not harm to give
it an explicit name, such as "non-encrypting OpenPGP".  That would help
clarify references to this document.

>> The goal, course and fine

The start of section 2 mentions a list of four bullets, specifying a few
techniques used.  I am not seeing CR-LF standardisation, but I do see
radix-64 which seems to be of similar weight.  Both are not nearly as
important as the first three points.  I would leave it to these three
bullets and not get down to the level of representation here.

To be frank, I don't see the point of section 2.4; it seems too early.
I may be off here.  Either way, isn't it true that implementations SHOULD
only *accept* radix-64 representations of OpenPGP data?

Somewhat funny: confidentiality is not mentioned here at all!

>> Procedures, data

Section 2.1 describes the same procedure twice.  Once in the
introductionary paragraph, once in the list.  What I would have expected
from the plaintext (not the list) in both 2.1 and 2.2 is a description of
the data structure -- that would remove procedurally irrelevant details
from the procedures.

Point 4 of 2.2, "attached" means "appended", so at the end, right?

Point 5 of 2.2, "keeps" means?  Should it be "receives"?

>> Compression

Section 2.3 stresses that compression SHOULD be done, but it is not
mentioned in the procedure under 2.1.

The second paragraph contradicts itself, doesn't it?  It speaks of
implementations that do not implement compression and says that they should
at least decompress.  This should be said about implementations that do not
compress outgoing messages prior to their encryption.

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.

Let me know if you want me to write actual text.  I'm not sure how this
process works -- but I'll be open to suggestions.

Cheers,

Rick van Rein,
OpenFortress.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 08 Feb 2005 06:21:49 +0000

> I think "OpenPGP data" will be fine, in contrast to "readable data".

"ciphertext" and "plaintext" sound more usual to me.

> compressing a message, the entropy of the data that is encrypted is made

Entropy is not altered by (lossless) compression.

Cheers,

Ben.

---

From: Rick van Rein <[email-masked]>
Date: Tue, 08 Feb 2005 10:00:20 +0100

Ben, others,

> 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