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

61–70 of 249 posts

Re: “Should you encrypt or compress first?”

#61

Post by lmm »

dllthomas wrote: post #57
phlo wrote: post #49

Earlier quoted context omitted.

That'll make an attack significantly more time-consuming, but won't prevent it. Instead of instand feedback whether they guessed correctly, an attacker would instead need to send a bunch of requests to determine if the average request size has decreased.

What if the number of padding bytes is a function of the contents?

That would add noise to the information the attacker gets, but ultimately the "output" length has to be correlated with the input length, so you can't ever get the amount of information the attacker gets down to zero which is what's needed to make a cipher secure.

Re: “Should you encrypt or compress first?”

#62

Post by witty_username »

lisper wrote: post #39
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.

> If you're encrypting a document, then compressing it first may prevent leaks.

I think this is only true if you use a bad encryption algorithm where same plaintext blocks have the same ciphertext.

Re: “Should you encrypt or compress first?”

#63

Post by b101010 »

vog wrote: post #50
sirk390 wrote: post #43

Earlier quoted context omitted.

I think, you mean whether to encrypt or sign first.

Good catch! Although the article talks about encrypt+sign versus sign+encrypt, the same argument goes for compress+sign versus sign+compress.

Why is the debate about "compress/encrypt then sign" vs "sign then compress/encrypt"?

Is there a non obvious problem with sign then compress/encrypt then sign again? (overcomplicated or unnecessary?)

Re: “Should you encrypt or compress first?”

#64

Post by witty_username »

IncRnd wrote: post #55
lisper wrote: post #39

Earlier quoted context omitted.

> 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.

Are you talking about compressing plain text larger than a block, then encrypting per each block of the compressed output?

@lisper

Stream ciphers.

Re: “Should you encrypt or compress first?”

#65

Post by hinkley »

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.

Does this really need to be said though?

I may be too close to the problem. I've had to explain this to project managers and customers of course, but this is hacker news.

It feels like a three page article on why you should put your socks on before your shoes and not after.

Re: “Should you encrypt or compress first?”

#66

Post by witty_username »

jessriedel wrote: post #53
DanBlake wrote: post #48

Earlier quoted context omitted.

>Compression after encryption is useless, as there should be NO recognizable patterns to exploit after the encryption. Not to nitpick, but this is incorrect. A encrypted file can very well have something like 100 X's in a row which the compression system could turn from XXXXXXXXXXXXXXXX.... into (100 x's go here) - Lousy example I know but it gets the point across. Its also easy enough to test- Just encrypt a file th…

No. If the encrypted output is randomly distributed, as it should be, then the expected number of bits cannot be reduced through compression. If it successfully compresses some files, it will make some files larger. For random data, the change will be negligible with overwhelming probability, plus there will be overhead.

@DanBlake

That's a text file, which doesn't use the full range of a byte (0-255), so each character takes less than a byte.

Re: “Should you encrypt or compress first?”

#67

Post by DanBlake »

witty_username wrote: post #66
jessriedel wrote: post #53

Earlier quoted context omitted.

No. If the encrypted output is randomly distributed, as it should be, then the expected number of bits cannot be reduced through compression. If it successfully compresses some files, it will make some files larger. For random data, the change will be negligible with overwhelming probability, plus there will be overhead.

@DanBlake That's a text file, which doesn't use the full range of a byte (0-255), so each character takes less than a byte.

Im happy to reproduce in other formats. The contents are still random which is the crux of the issue here.

Re: “Should you encrypt or compress first?”

#68

Post by mikeash »

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.

...Eventually. It takes quite a while to get there, and still treats the question as legitimate, when it's loaded and really makes no sense.

Re: “Should you encrypt or compress first?”

#69

Post by lisper »

witty_username wrote: post #62
lisper wrote: post #39

Earlier quoted context omitted.

> 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.

> If you're encrypting a document, then compressing it first may prevent leaks. I think this is only true if you use a bad encryption algorithm where same plaintext blocks have the same ciphertext.

Oh, I'm not talking about leaking plaintext, I'm talking about leaking the length of the document.

Re: “Should you encrypt or compress first?”

#70

Post by charleslmunger »

DanBlake wrote: post #60
jessriedel wrote: post #53

Earlier quoted context omitted.

No. If the encrypted output is randomly distributed, as it should be, then the expected number of bits cannot be reduced through compression. If it successfully compresses some files, it will make some files larger. For random data, the change will be negligible with overwhelming probability, plus there will be overhead.

Using a random text generator http://pasted.co/encrypted.txt ( 10,002 bytes ) Then compressed it with winrar http://pasted.co/compressed.rar ( 7,743 bytes ) Roughly 20% compression isnt meaningless- so I fail to see why you are just giving a flat 'no' when its obvious what you are saying is untrue.

Your random text isn't uniformly random - any byte that isn't a letter or number never shows up.
Post reply on HN