Hacker News Reader

Comment by usloth_wandows | Hacker News Reader

I thought this was common sense. Compress then encrypt. Encryption leads to higher entropy, therefore less effective compression.

View on HN

The article is about why that can be wrong.

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

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?

A lot, possibly a majority, of the major breaks in crypto systems (certainly the interesting ones) in the past decade have been because of compressing before encrypting. If someone wants to compress first, demand that they justify the reduced bandwidth usage.

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

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

You've just created an amplified DOS vulnerability :)

If security is the top concern, making all encrypted messages the same length would be ideal as far as I can tell. That way, all you are giving away is an upper bound on the message size. Padding with random noise to a uniform length (with the payload either compressed or not) and then encrypting should be the most secure option.

What's the point of compressing if you're just going to pad it anyway? If you're worried about security just encrypt and don't compress.

The point in that case is to combat plain text (known value) attacks.

Precisely how the padding / extra padding is distributed within the data stream to be encrypted is also an issue. The goal is to make it very difficult to guess where data will be represented if you do happen to know the plain text.

The article agrees, as should anyone who understands encryption and compression: encrypted data can't be compressed, so encrypt-then-compress is pointless.

The article also covers why compress-then-encrypt is dangerous. But it's not a dichotomy. Those aren't your only two choices, you can also just encrypt and not compress.

Did you read the article?

Read the article smarty pants ;-)

Compressing then encrypting gives you more effective compression and (somewhat) less effective encryption. Encrypting then compressing gives you more effective encryption and less effective (almost ineffective) compression. So, depends which one you want more. :)

Compression after encryption is likely to be worse then ineffective - it's almost certain to be higher bandwidth than no compression.

Yeah, running an encrypted bitstream through a lossy encoder like CELP is going to sound pretty awful (i.e., the content will be completely unrecoverable.) The whole idea behind a speech codec is to simplify the frequency-domain properties of the data in one way or another.

People are missing the real takeaway from the article, which is that VBR speech compression has serious vulnerabilities that CBR codecs won't share. That part wasn't obvious.

Are you sure? Is that your final answer?

Reply on news.ycombinator.com