Subject: compression/encryption order

From: "Richard E. Silverman" <[email-masked]>
Date: Sun, 10 Sep 2000 22:24:55 -0400 (EDT)

As far as I can tell, the transport draft does not actually say in what
order encryption and compression should take place.  Of course, it's
normal practice to compress first, then encrypt -- and this is what all
the implementations do -- but still it should be explicit.

If I've missed it somehow, I'm sure my oversight will be promptly
corrected.  :)

-- 
  Richard Silverman
  [email-masked]

---

From: [email-masked] (Niels M�ller)
Date: 11 Sep 2000 10:03:38 +0200

> the implementations do -- but still it should be explicit.

I think the transport draft does specify the correct order, although
it might be a good idea to make that more explicit. More precisely,
the current draft says:

: 4.  Binary Packet Protocol
: 
: Each packet is of the following format.
: 
:   uint32    packet_length
:   byte      padding_length
:   byte[n1]  payload; n1 = packet_length - padding_length - 1
:  
:   byte[n2]  random padding; n2 = padding_length
:   byte[m]   mac (message authentication code); m = mac_length
: 
:     packet_length
: 	The length of the packet (bytes), not including MAC or the
: 	packet_length field itself.
: 
:     padding_length
: 	Length of padding (bytes).
: 
:     payload
:! 	The useful contents of the packet.  If compression has been
:! 	negotiated, this field is compressed.  Initially, compression MUST
:! 	be "none".
: 
:     Padding
: 	Arbitrary-length padding, such that the total length of
: 	(packet_length || padding_length || payload || padding) is a
: 	multiple of the cipher block size or 8, whichever is larger.
: 	There MUST be at least four bytes of padding.  The padding SHOULD
: 	consist of random bytes.  The maximum amount of padding is 255
: 	bytes.
: 
:     MAC
: 	Message authentication code.  If message authentication has been
: 	negotiated, this field contains the MAC bytes.  Initially, the MAC
: 	algorithm MUST be "none".

...

: 4.3.  Encryption
: 
: An encryption algorithm and a key will be negotiated during the key
: exchange.  When encryption is in effect, the packet length, padding
:!length, payload and padding fields of each packet MUST be encrypted with
: the given algorithm.

/Niels

---

From: "Richard E. Silverman" <[email-masked]>
Date: Mon, 11 Sep 2000 04:34:48 -0400 (EDT)

On 11 Sep 2000, Niels Möller wrote:

> the current draft says: ...

I noticed this when reading it, but I find it ambiguous.  In one way of
reading, it does imply an order: "payload" is defined as compressed if
compression is on, and encryption is defined as operating on the payload.
However, the title of the section is "Binary Packet Protocol;" it
describes the format of a packet in general -- and it does not say whether
it is describing it before or after encryption.  A packet after encryption
is just as much a "packet" as one before, so in that sense it's not clear
whether the direction to compress the payload "if compression has been
negotiated" applies to the payload before or after encryption.

-- 
  Richard Silverman
  [email-masked]

---

From: "Michael H. Warfield" <[email-masked]>
Date: Mon, 11 Sep 2000 09:01:39 -0400

> the implementations do -- but still it should be explicit.

	If you think about it, compression before encryption is the only
one that really makes sense.  If you encrypted it first, the compression
would be unable to do much.  Ideally, the encryption should result in
data that looks very similar to noise and not very compressible.  Making
it "explicit" may be something on the order of making the obvious more
apparent.

-- 
 Michael H. Warfield    |  (770) 985-6132   |  [email-masked]
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

---

From: Baruch Even <[email-masked]>
Date: Mon, 11 Sep 2000 18:46:48 +0200 (IST)

> it "explicit" may be something on the order of making the obvious more

It is true, but I think that for completeness sake it should be stated
explicitly, there might be a need for a programmer not well versed in
cryptography to implement the algorithms and such a fact is better stated
explicitly then left to the unwary to worry about.

Baruch

---

From: "Richard E. Silverman" <[email-masked]>
Date: Mon, 11 Sep 2000 12:14:35 -0400 (EDT)

Michael and Mika have opined that there's no need to make the
compression/encryption order more explicit in the draft, because it's
obvious and common knowledge.  I'm aware of the reasons for doing it this
way; that's why I wrote:

res> Of course, it's normal practice to compress first, then encrypt ...

Obviously, I should have been more explicit about what I meant.  :)

Anyway, I disagree strongly with this point of view.  Something being
obvious is not a reason to leave it out of a specification, or to leave it
obscure or unclear.  *Everything* in a specification should be explicit;
that's why it's a specification and not a poem.  Opinions on "obviousness"
vary widely, and any ambiguity is an opportunity for future
incompatibility among implementations, perhaps in a context we can't think
of now in which the point is not so clear.  Belaboring the obvious is a
small price to pay for avoiding that.

-- 
  Richard Silverman
  [email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 11 Sep 2000 13:11:09 -0400

Since the draft is due for a revision anyway, sounds like it should be
clarified to say "compress, then encrypt".  Any strong objections?

					- Bill

---

From: "Michael H. Warfield" <[email-masked]>
Date: Mon, 11 Sep 2000 14:35:47 -0400

On Mon, Sep 11, 2000 at 12:14:35PM -0400, Richard E. Silverman wrote:

	[...]

> small price to pay for avoiding that.

	I'm fine with that as long as...

	1) We recognize that we are belaboring the obvious.

	2) We do not go so overboard in belaboring the obvious that the
standard becomes unreadable.

	I agree that abiguity is bad and should be avoided at all cost.

	Mike