3 ms·

Logically speaking, an encrypted file should have a high entropy set of bits within it. Compressing it would be low return, but higher security since the input

Logically speaking, an encrypted file should have a high entropy set of bits within it. Compressing it would be low return, but higher security since the input file contained more "random" bits. Compressing the source material will yield smaller results but will be more predictable as the file will always contain ZIP headers and other metadata that would possibly make decryption of your file much easier.

danielweber 10y ago
It's not just the headers. You could strip those off and count on the other side to put them back on. It's that the act of decompressing arbitrary data can leak very important information to the attacker.
tansey 10y ago
Most (good) encryption schemes have the property that knowing part of the message, or some other information like message length, will not help you decrypt the message.
pizza234 10y ago
> Compressing the source material will yield smaller results but will be more predictable This depends on the susceptibility of the ciphers to known-plaintext attack; I'm not sure if today there are scenarios where using such ciphers makes sense.
tankenmate 10y ago
But the metadata is a form of structured data and as you state is semi known plaintext; i.e. the structure is known, and to a lesser extent also the data (some fields have a known or limited range of possibilities). Aside from the headers the compressed data it self often has structure; take the Lempel Ziv class of dictionary encoders rely on repeating data to compress. It is just this fact that it is repeating means that you can guess with much higher probability than normal what certain bytes will _not_ be (because longest words that match the dictionary are chosen to tokenised to maximise compression); i.e. bytes that _don't_ match a word suffix in the dictionary will restart the search for a new matching word / token pair. Having said that the plaintext itself is almost never random; but the key thing does the attacker have any crib that might be used to have a good first guess that can reduce the amount of work required. So which is more guessable; the semi-structure, at the byte level, of compressed data, or the possible semi-structure of the original plain text? If you are dealing with a protocol that specifies compression (and in particular which compression method) you may have given away part of the game. One way is to "bump up" the entropy and add "chaff" to the compressed stream before encryption; i.e. add some entropy but less than what would be less than the amount saved through compression. My gut feel is that the efficacy of this would vary depending on plaintext, compression method, and encryption method. You also run the risk of side channel analysis via CPU, RAM, power usage etc.
- gravypod 10y ago
  The input 'plaintext' could be binary data or other information that the attacker cannot predict. What they can predict if they find some code interfacing with this encrypted file is the way it has been stored. It's not much of a long shot to say that if you can identify that it's just a plain zipped file then you're job will be much easier when it comes to reverse engineering this. That being said, it's still a huge pain in the ass to work with that stuff. I mean, the US government hires some of the worlds best crypto people in the world and they still are sent for a run some times.
deleted 10y ago
[deleted]

danielweber 10y ago

It's not just the headers. You could strip those off and count on the other side to put them back on. It's that the act of decompressing arbitrary data can leak very important information to the attacker.

tansey 10y ago

Most (good) encryption schemes have the property that knowing part of the message, or some other information like message length, will not help you decrypt the message.

pizza234 10y ago

> Compressing the source material will yield smaller results but will be more predictable This depends on the susceptibility of the ciphers to known-plaintext attack; I'm not sure if today there are scenarios where using such ciphers makes sense.

tankenmate 10y ago

But the metadata is a form of structured data and as you state is semi known plaintext; i.e. the structure is known, and to a lesser extent also the data (some fields have a known or limited range of possibilities). Aside from the headers the compressed data it self often has structure; take the Lempel Ziv class of dictionary encoders rely on repeating data to compress. It is just this fact that it is repeating means that you can guess with much higher probability than normal what certain bytes will _not_ be (because longest words that match the dictionary are chosen to tokenised to maximise compression); i.e. bytes that _don't_ match a word suffix in the dictionary will restart the search for a new matching word / token pair. Having said that the plaintext itself is almost never random; but the key thing does the attacker have any crib that might be used to have a good first guess that can reduce the amount of work required. So which is more guessable; the semi-structure, at the byte level, of compressed data, or the possible semi-structure of the original plain text? If you are dealing with a protocol that specifies compression (and in particular which compression method) you may have given away part of the game. One way is to "bump up" the entropy and add "chaff" to the compressed stream before encryption; i.e. add some entropy but less than what would be less than the amount saved through compression. My gut feel is that the efficacy of this would vary depending on plaintext, compression method, and encryption method. You also run the risk of side channel analysis via CPU, RAM, power usage etc.

gravypod 10y ago
The input 'plaintext' could be binary data or other information that the attacker cannot predict. What they can predict if they find some code interfacing with this encrypted file is the way it has been stored. It's not much of a long shot to say that if you can identify that it's just a plain zipped file then you're job will be much easier when it comes to reverse engineering this. That being said, it's still a huge pain in the ass to work with that stuff. I mean, the US government hires some of the worlds best crypto people in the world and they still are sent for a run some times.

deleted 10y ago

[deleted]