The challenge gives us the description that there is some ChaCha20 implementation, and searching Google for the name of the challenge shows some hints about this implementation being done “incorrectly”. Hence we should take a look at the way that ChaCha20 is supposed to be implemented. One good resource is RFC 8439, clicking on the link should take you to the page that contains the high-level pseudocode of how ChaCha20 works.

The encrypt function appends the flag to the plaintext provided by the user. However, the concatenated string is passed to zlib for compression before encrypting. There are no evident weakness in the use of AES-CTR, hence this challenge has to do with some properties of zlib. Indeed, after fuzzing for a while, it seems like zlib was eliminating duplicate strings - hence a correct guess of a portion of the flag will result in a shorter resulting plaintext compared to the resulting ciphertext from a incorrect guess.

This challenge documents the ZeroLogon vulnerability, which is a critical vulnerability originating from a cryptographic authentication protocol failure in Microsoft Active Directory. There is a ZeroLogon whitepaper, which is useful in solving this challenge. The underlying encryption scheme in both the challenge and the Microsoft Active Directory is the AES-CFB8. The encryption method should be clearly demonstrated in the paper. In the challenge, the encrypt method is not in use and only serve as a red herring.

The ciphertexts in the challenge are encrypted with AES-CTR with the same, new zero counter. Hence, the keystream used to xor the plaintexts to obtain the ciphertexts will be the same for all ciphertexts. This now becomes the classic, and taught by many cryptographic courses in universities worldwide about the many time pad. The one-time pad cannot be used multiple times (hence the name) because an attacker can xor the two ciphertexts to obtain the xor of the corresponding plaintext.

I did not manage to solve this, I was trying to brute force the IV used in the challenge, but seems like $2^{64}$ possibilities of possible IVs is simply too many for my laptop to handle. Peek at the solution and I’m glad I did because there is no shot that I know this. DES, or 3DES also, suffer the problem of weak keys. These are keys that cause the encryption mode of DES to act identically to the decryption mode of DES (albeit potentially that of a different key).