5 ms·
"Don't compress at all" is the better default answer. Noting that "compression after encryption is stupid."
by 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.