ADC encryption and compression

Technical discussion about the NMDC and <a href="">ADC</A> protocol. The NMDC protocol is documented in the <a href="">Wiki</a>, so feel free to refer to it.

Moderator: Moderators

Posts: 20
Joined: 2003-11-12 20:11
Location: Täby, Sweden

ADC encryption and compression

Post by Dolda2000 » 2006-08-16 08:56

I find that the ADC spec is a bit unclear about the combination of encryption and compression (either that, or I'm a bit blind). Should incoming traffic be decrypted first, and then decompressed, or should it be decompressed first, and then decrypted?

Forum Moderator
Posts: 699
Joined: 2003-03-04 12:16

Post by Todi » 2006-08-16 09:33

Just a guess, but wouldn't un-encrypted traffic compress better than encrypted traffic? Atleast for filelists, searches, and the like. I.e, compress, encrypt, send. Recieve, decrypt, decompress.

Posts: 34
Joined: 2003-05-01 10:49

Post by FarCry » 2006-08-16 17:33

The encryption is of course the lowest layer. Anything else would be technically complicated.

Posts: 337
Joined: 2003-01-06 13:32

Post by cologic » 2006-08-17 20:36

A couple more points:

(1) Ciphertext should contain no evident structure, and thus should be incompressible. Detectable structure would allow for easier cryptanalysis, all else equal. Thus, ideally, C = compress(encrypt(P)) should be no more effective bandwidthwise than E = encrypt(P), and therefore pointless. This isn't the case for C = encrypt(compress(P)).

(2) Defending against cryptanalysis plays into this preference as well in that structure (such as repetition) in plaintext might seep out through (this is one of the bases of known-plaintext cryptanalysis, where one intentionally feeds a cipher known data) the encryption function. First compressing the plaintext ameliorates such a threat. Again, this argues for C = encrypt(compress(P)).