4 ms·
I thought this was common sense. Compress then encrypt. Encryption leads to higher entropy, therefore less effective compression.
by usloth_wandows 10y ago
I thought this was common sense. Compress then encrypt. Encryption leads to higher entropy, therefore less effective compression.
- danielweber 10y agoThe article is about why that can be wrong.
- mozumder 10y agoBut in almost all cases it's right.
- danielweber 10y ago"Don't compress at all" is the better default answer. Noting that "compression after encryption is stupid."
- mozumder 10y agoThe 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?
- danielweber 10y agoA 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.
- IncRnd 10y agoThe interview in the article is for a security position. You answer is incorrect in that situation.
- SubiculumCode 10y agoyeah, but what about compress, encrypt, compress, encrypt .. compress? :)
- IncRnd 10y agoYou've just created an amplified DOS vulnerability :)
- richard_todd 10y agoIf 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.
- Miner49er 10y agoWhat'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.
- mjevans 10y agoThe 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.
- mikeash 10y agoThe 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.
- iancarroll 10y agoDid you read the article?
- geofft 10y agoCompressing 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. :)
- richardwhiuk 10y agoCompression after encryption is likely to be worse then ineffective - it's almost certain to be higher bandwidth than no compression.
- CamperBob2 10y agoYeah, 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.
- IncRnd 10y agoAre you sure? Is that your final answer?
- igorgue 10y agoRead the article smarty pants ;-)