The Word You Already Know: Crib Dragging a Repeating-Key XOR
The challenge
Thornbury's deploy tool writes an encrypted copy of each service's environment file next to the plain one, and somebody committed the encrypted ledger file without the plain one. The tool calls it encryption. It is a repeating-key XOR, and the key is a word nobody wrote down. You do not need the key to start, because every environment file this tool produces begins with the same twelve characters, and XOR gives you back whatever you feed it that you did not put in. Recover the key, then read out the database password.
What you'll learn
- Explain why XOR is its own inverse and what that means for key recovery
- Use a known plaintext prefix as a crib to extract a repeating key
- Recognise a repeated pattern in output as confirmation the crib was right
- Apply the recovered key to decrypt the whole message
- Identify the fixed file formats that make cribs available in practice
Skills tested
Prerequisites
- What XOR does bit by bit
- Reading hex
How it works
XOR has one property that decides everything about this: applying the same value twice returns the original. Encryption is ciphertext = plaintext XOR key, so decryption is plaintext = ciphertext XOR key, and the third arrangement is the one attackers use: key = ciphertext XOR plaintext. If you can guess any stretch of the plaintext, you get the key bytes that sat under it, for free.
That guess is called a crib, and it is almost always available. Real data has fixed openings: an environment file starts with a variable name, an HTTP response starts with HTTP/1.1, a PNG starts with its signature, JSON starts with a brace. When the key repeats and is shorter than the crib, the recovered bytes repeat too, and that repetition is your proof: noise means the guess was wrong, a visible cycle means it was right and tells you the key's length in the same glance.
A one-time pad avoids all of this by being as long as the message and never reused. A six-letter key XORed over a whole file is not a weaker version of that idea, it is a different thing entirely: the key is recoverable from any correctly guessed fragment, and after that the file is plaintext.
Common mistakes
- Looking for a chain that decodes in one pass. The first XOR is a measurement, not a decryption. You run the tool twice with different keys.
- Giving up when the output turns to noise. Only the span covered by the crib is meaningful. Everything after it is expected garbage.
- Using the whole repeated string as the key.
PLOVERPLOVERis the key written twice. Use one copy. - Forgetting to decode the hex first. XOR operates on bytes. Applied to the hex text itself it produces nothing useful.
- Omitting the equals sign from the crib.
ENVIRONMENTis eleven characters andENVIRONMENT=is twelve; a shorter crib still works here, but every character you get right is one more key byte confirmed.
How to defend against it
Neither half of this should exist: the encryption or the file.
- Do not put secrets in the repository, encrypted or otherwise. Inject them at deploy time from a secret manager, so there is no artefact to commit.
- If files must be encrypted at rest in a repo, use a real tool with authenticated encryption and managed keys. Homemade XOR is not a weak cipher, it is an encoding with a password-shaped argument.
- Scan commits for high-entropy blobs as well as for plaintext keys. This file would pass any regex looking for
DB_PASS=. - Rotate the credential now. It was committed, so treat it as public from the moment of the commit, not from the moment somebody noticed.