Compression-Ratio Side Channel
Here's the basic idea. Encryption ideally hides all information about the encrypted data. But in practice, that isn't completely true: encryption reveals the size of the encrypted data, at least within a few bytes. For example, suppose that you know that the answer is “yes” or “no”, and you see the following message encrypted with AES-CTR:

82a801950ca7aaeea0685afc86b44b70 15c0


You know it's a two-byte message (plus 16-byte IV) so it's “no”.

Now suppose that you have a fixed-size message (or more generally a message where the attacker knows the approximate size anyway, because it's given by the protocol), but it's compressed before encrypted. Compression exploits redundancy in the message. So if the encrypted message is a lot smaller than the expected size of the plaintext, that means a highly redundant message; if the encrypted message is about as large as the expected size of the plaintext, that means a message with low dedundancy.

Low/high repetition, on its own, is typically not meaningful to an attacker. But what if the attacker can inject some text into the message? Then the size of the encrypted compressed message reveals redundancy between the part that's injected by the attacker and the confidential part. Now there's room for a damaging attack.

In cryptography, and more generally in the study of computation, an oracle is a black box which receives inputs and produces outputs. The oracle's outputs may not be possible to obtain without the oracle. In cryptography, a common kind of oracle is one that knows a secret key that the attacker doesn't have, but the oracle will only respond in certain specific ways, it won't just reveal the key. For example, a basic encryption oracle is willing to encrypt any plaintext but won't decrypt anything, allowing attempts to perform chosen-plaintext attack.

In this challenge, you're asked to study a particular kind of encryption oracle which combines the submitted plaintext with some fixed confidential text, and compresses the whole message. By submitting a lot of different partial plaintexts, and measuring how the length of the whole message varies depending on the submitted plaintext, the attacker gains information about the fixed confidential part. For example, submit aaaaaaaa, bbbbbbbb, cccccccc, etc. and see how the compressed length varies to get a rough ideas of how many a's, b's, c's, etc. there are in the confidential part. Repeat with digrams, trigrams, etc. If the confidential text is some kind of password $P$, that can turn an exponential attack (try all possible passwords of the known length) into a linear attack (figure out the first character because it's the character $c$ for which $c^n P$ gives the best compression, then repeat for each subsequent character).

The basic principle has been well-known for a long time. It's mentioned in John Kelsey's 2002 paper “Compression and Information Leakage of Plaintext”. But few people thought about the concrete applications until it was widely publicized as the CRIME attack on TLS. CRIME exploits compressed TLS streams which contain both a fixed confidential part (cookie for a web page) and a varying attacker-chosen part (e.g. an injected ad that makes callbacks). If you look around CRIME, you'll find a lot of literature on the topic, including Thomas Pornin's detailed write-up before the attack was published.