12 ms·
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 expe
by nightcracker 10y ago
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.
- vog 10y agoThis is exactly what the article says.
- loeg 10y agoThe troublesome part is the headline.
- JshWright 10y agoYeah, but the article uses a lot more words to say it...
- hinkley 10y agoDoes 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.
- yellowstuff 10y agoIt's not just you. I've never used encryption or compression in any serious way, but the right answer seems obvious if you know the definitions of encryption and compression.
- ghshephard 10y agoReally? I've been reading, and following encryption news for 10+ years, and it had never occurred to me that you should not compress prior to encrypting. The article was an eye opener for me - in hindsight, maybe obvious, but I bet 90% of your average technical audience wouldn't realize that you should not compress prior to encrypting.
- hinkley 10y agomea culpa. I am guilty of not waiting around for him to get to his point 3/4 of the way through the article. If you're trying to bring up subtle issues, don't bury the lede. What he's really trying to say is that you shouldn't compress sensitive data at all. And now we're into the non obvious stuff that some of us are clearly talking past each other about. Personally, I think he's painting too broad a stroke and some domains don't have this problem, and for some there are other factors at play such as insufficient block size giving away too much information. You could for instance probably figure out who is speaking just by the pattern of pauses, without even trying to decrypt what is said. And then there's session cookies, which I despair of ever being secure. Because of the chosen plaintext of CRIME, even a large block size would only make the setup phase take a bit longer (finding a message that is one byte bigger than the block size). Encryption is insufficient to protect shared secrets.
- mcguire 10y agoOnce upon a time I was at a talk given by a visiting professor (associated, I think, with the Horus project[1]; I'm reasonably sure some of you would recognize the name if I could remember it) on designing network protocols using plug-n-play software components. The illustrations he showed used Lego bricks. His big example was a Lego brick labelled "Compression" and another brick labelled "Encryption", and how you could arbitrarily compose them to achieve different protocols. Meanwhile, I was sitting at the back of the room wearing my "I'm not a security guy, but this is garbage" look. [1] http://www.cs.cornell.edu/info/projects/horus/main.html http://www.cs.cornell.edu/info/projects/horus/main.html
- mikeash 10y ago...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.
- shawnz 10y agoThe article seems to suggest that encrypt-then-compress would be the right solution in some circumstances, but really that's just as effective as encryption only with no compression. I don't feel the article is totally clear about this.
- lisper 10y ago> 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.
- IncRnd 10y agoAre you talking about compressing plain text larger than a block, then encrypting per each block of the compressed output?
- lisper 10y agoYes, of course. What would be the alternative?
- IncRnd 10y agoThank you. Your comment wasn’t clear for several reasons. Stream ciphers are regularly blocked in TLS, compression can occur per block. Compression may be done per block, not just against a file larger than a single block.
- witty_username 10y ago@lisper Stream ciphers.
- DanBlake 10y ago>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 then compress it. Sometimes it will be smaller. (Your reply indicated that in 100% of attempts compression is impossible)
- jessriedel 10y agoNo. 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 10y agoUsing a random text generator http://pasted.co/encrypted.txt http://pasted.co/encrypted.txt ( 10,002 bytes ) Then compressed it with winrar http://pasted.co/compressed.rar 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.
- charleslmunger 10y agoYour random text isn't uniformly random - any byte that isn't a letter or number never shows up.
- DanBlake 10y agoHere it is encrypted with AES256 - Pass is wasteoftime http://pasted.co/wasteoftime.txt http://pasted.co/wasteoftime.txt 4,732 bytes http://pasted.co/wasteoftime.rar http://pasted.co/wasteoftime.rar 3,753 bytes Also, if there is issues with using the 'wrong' encryption, I feel thats kind of a straw man argument. Please feel free to upload a file over 5MB which cant be reduced in size through any of the various compression tools. Also, keep in mind that I never said it would be a huge benefit at all- I only said that SOME compression was possible SOME of the time.
- api 10y agoThe rule is: never compress something secret together with something potentially attacker-influenced. If the attacker can influence the traffic, they can potentially gather information about the secret by examining the effect of differing traffic patterns on the size of the encrypted result.
- TorKlingberg 10y agoNo, the rule is: never compress something secret together with something potentially attacker-influenced, at least if the length of the compressed data leaks.
- api 10y agoFixed. That was a typo/thinko.
- deleted 10y ago[deleted]
- AgentME 10y agoThat's an excellent rule, but that doesn't cover the other example used about voice communications.
- jessriedel 10y agoFor others: https://en.wikipedia.org/wiki/CRIME https://en.wikipedia.org/wiki/CRIME
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- coroutines 10y agoFrom my very not-a-crypto-person perspective, I had thought compression was fine as long as you don't pad it to the expected block length before encrypting? something something padding oracle
- gcommer 10y agoThe paper linked in the article: "Phonotactic Reconstruction of Encrypted VoIP Conversations"[1] specifically works in a situation without padding because the compression scheme affects the length of packets in a semantic way. [1] http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf
- deleted 10y ago[deleted]