Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Should you encrypt or compress first?”

blog.appcanary.com

Post reply on HN
Print view View original

31–40 of 249 posts

Re: “Should you encrypt or compress first?”

#31

Post by JoshTriplett »

tomp wrote: post #2

I don't understand... Why couldn't you do CRIME with no compression as well? Assuming you can control (parts of) the plaintext, surely plaintext+encrypt gives you more information than plaintext+compress+encrypt?

If you have a blob of encrypted data, that should normally tell you nothing about the plaintext, except its approximate length (assuming it wasn't padded). Normally, the length of the plaintext should tell you very little about its content; it doesn't do you much good to know "the message is about 4096 bytes". However, if you compress first, then you know the approximate length of the compressed data, which means you know something about the content of the plaintext.

As one of several possible attacks: imagine the attacker could supply data that will get fed back to them in the encrypted blob, along with your own data, and all compressed together. The blob will compress better if your data matches their data. So, repeatedly feed in your data and get back blobs, watching the total size of the compressed-then-encrypted blob, and you can predict enough about their data to guess it.

Re: “Should you encrypt or compress first?”

#32

Post by tankenmate »

gravypod wrote: post #5

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.

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.

Re: “Should you encrypt or compress first?”

#33

Post by [deleted] »

gravypod wrote: post #5

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.

[deleted]

Re: “Should you encrypt or compress first?”

#34

Post by SubiculumCode »

danielweber wrote: post #21
mozumder wrote: post #10

Earlier quoted context omitted.

But in almost all cases it's right.

"Don't compress at all" is the better default answer. Noting that "compression after encryption is stupid."

yeah, but what about compress, encrypt, compress, encrypt .. compress?

:)

Re: “Should you encrypt or compress first?”

#36

Post by JshWright »

vog wrote: post #26
orlp wrote: post #14

There's no compress or encrypt _first_. It's just compress or not, before encrypting. If security is important, the answer to that is no, unless you're an expert and familiar with CRIME and related attacks. Compression after encryption is useless, as there should be NO recognizable patterns to exploit after the encryption.

This is exactly what the article says.

Yeah, but the article uses a lot more words to say it...

Re: “Should you encrypt or compress first?”

#39

Post by lisper »

orlp wrote: post #14

There's no compress or encrypt _first_. It's just compress or not, before encrypting. If security is important, the answer to that is no, unless you're an expert and familiar with CRIME and related attacks. Compression after encryption is useless, as there should be NO recognizable patterns to exploit after the encryption.

> If security is important, the answer to that is no

It's a little more nuanced than that. Compression may cause information leaks or it can prevent them depending on the circumstances. If you're encrypting an audio stream, then compressing it first can cause leaks. If you're encrypting a document, then compressing it first may prevent leaks.

Re: “Should you encrypt or compress first?”

#40

Post by IncRnd »

mozumder wrote: post #25
danielweber wrote: post #21

Earlier quoted context omitted.

"Don't compress at all" is the better default answer. Noting that "compression after encryption is stupid."

The correct default answer is encrypt after compress. "Don't compress at all" doesn't help you if you need to reduce bandwidth. What good is a secure channel if no one uses it because of its high bandwidth requirements?

The interview in the article is for a security position. You answer is incorrect in that situation.
Post reply on HN