191–200 of 249 posts
Earlier quoted context omitted.
You can't compress after encryption. Encrypted content should be indistinguishable from random data. So encrypt than compress shouldn't be able to yield any reasonable compression.
wit truly random data, patterns should randomly appear.
Earlier quoted context omitted.
You can't compress after encryption. Encrypted content should be indistinguishable from random data. So encrypt than compress shouldn't be able to yield any reasonable compression.
wit truly random data, patterns should randomly appear.
What this short proof shows is that even though random data may have patterns, no compression algorithm can successfully leverage this for every random string.
Can't you just add some random length data at the end. You are defeating compression a little bit, but are also making the length non deterministic. I thought pgp did that.
So if the length of the resulting message is leaking information, salt it by adding some extra random bits to the end to increase the length by a random amount.
In general, it is safe to assume that whatever countermeasure you are thinking of has already been defeated by an attacker, unless you have researched for a really long time and found no possible alternative.
Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Entropy_(information_theory)
I'm sorry, that article is far too long to tell me what you are trying to say. All I can gather is, I was wrong
Earlier quoted context omitted.
It'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.
Really? 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.
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.
Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Entropy_(information_theory)
I'm sorry, that article is far too long to tell me what you are trying to say. All I can gather is, I was wrong
A more interesting question is whether to compress or sign first. There's an interesting article on that topic by Ted Unangst: "preauthenticated decryption considered harmful" http://www.tedunangst.com/flak/post/preauthenticated-decrypt... EDIT: Although the article talks about encrypt+sign versus sign+encrypt, the same argument goes for compress+sign versus sign+compress. You shouldn't do anything with untrusted dat…
The OP should take https://www.coursera.org/learn/crypto