3 ms·

Once upon a time, roughly the mid '90s, I attended a talk by somebody from the Horus Project (https://www.cs.cornell.edu/info/projects/horus/); https://www.cs.c

Once upon a time, roughly the mid '90s, I attended a talk by somebody from the Horus Project (https://www.cs.cornell.edu/info/projects/horus/); https://www.cs.cornell.edu/info/projects/horus/); mercifully, I've forgotten who it was. Anyway, this person was blathering on and on about the Lego model of network protocol components and how you could build new protocols quickly by stacking different blocks and only needed to build your specific functionality into a block to re-use the other components. See Horus: A Flexible Group Communications System (https://www.cs.cornell.edu/home/rvr/papers/HorusFlexible.pdf https://www.cs.cornell.edu/home/rvr/papers/HorusFlexible.pdf) for an example. Anyway, in their slides, the example was two Lego bricks labelled "Encryption" and "Compression", which were shown stacked in the two different orders. The problem is that doesn't work. You cannot compress something that has been encrypted. Those two blocks do not commute. I was, unfortunately, too much of a gutless larval grad student to bring this up at the talk, though.

tialaramex 6y ago
Even better, while compressing a good quality ciphertext doesn't work - enciphering a compressed stream may introduce more problems than if it had not been compressed first. This doesn't look like a real world problem and I can believe that in "the mid '90s" a cryptographer who pointed out that it's a bad idea would have been dismissed for focusing on a purely academic concern. In a cryptographer's model an adversary who is able to use your system to encrypt plaintext partially or entirely of their choosing is a reasonable hypothetical, but in the real world such adversaries were rare. Who lets somebody else choose part of the messages they're encrypting? The Web offers a concrete answer in the form of: Cookies, HTTPS and Javascript. Bad guys get to cause you to encrypt a mixture of their chosen plaintext plus a cookie value they don't yet know. Is that a problem? Well... if you compress the data before encrypting then the bad guys get to see whether it compresses more or less with their chosen input, and you've got CRIME (and later BREACH).

tialaramex 6y ago

Even better, while compressing a good quality ciphertext doesn't work - enciphering a compressed stream may introduce more problems than if it had not been compressed first. This doesn't look like a real world problem and I can believe that in "the mid '90s" a cryptographer who pointed out that it's a bad idea would have been dismissed for focusing on a purely academic concern. In a cryptographer's model an adversary who is able to use your system to encrypt plaintext partially or entirely of their choosing is a reasonable hypothetical, but in the real world such adversaries were rare. Who lets somebody else choose part of the messages they're encrypting? The Web offers a concrete answer in the form of: Cookies, HTTPS and Javascript. Bad guys get to cause you to encrypt a mixture of their chosen plaintext plus a cookie value they don't yet know. Is that a problem? Well... if you compress the data before encrypting then the bad guys get to see whether it compresses more or less with their chosen input, and you've got CRIME (and later BREACH).