A system that decrypts a message before it checks whether the message is authentic has handed the attacker a tool. The cryptographic doom principle is one sentence, but it explains a decade of TLS vulnerabilities, the reason padding oracles exist, and why modern protocols stopped letting engineers choose the order at all.
Encryption keeps a message secret. A message authentication code (MAC) proves the message was not altered and came from someone holding the right key. Most secure channels need both, so they combine a cipher with a MAC. The surprising part is that the order in which you apply those two operations is not a matter of taste. Get it wrong and you can build a channel that leaks the plaintext it was supposed to protect, even though every individual primitive is sound.
Moxie Marlinspike named the rule in 2011, and the phrasing has stuck because it is blunt:
If you have to perform any cryptographic operation before verifying the MAC on a message you have received, it will somehow inevitably lead to doom.
— Moxie Marlinspike, "The Cryptographic Doom Principle," 2011
The operative word is before. Decryption is a cryptographic operation. If you decrypt first and verify second, you are processing attacker-controlled bytes with your secret key before you have any assurance those bytes are legitimate. Everything observable about that processing, including how long it takes and whether it throws an error, becomes a signal the attacker can read.
The three ways to combine a cipher and a MAC
There are three classical constructions, and they differ only in sequencing.
| Construction | What gets authenticated | Used by |
|---|---|---|
| Encrypt-and-MAC | The plaintext. Ciphertext and MAC are sent side by side. | SSH (transport layer, classic mode) |
| MAC-then-Encrypt | The plaintext, then the whole thing is encrypted together. | TLS 1.0 through 1.2 (CBC cipher suites) |
| Encrypt-then-MAC | The ciphertext. The MAC covers exactly what travels on the wire. | IPsec, and the TLS Encrypt-then-MAC extension (RFC 7366) |
Only encrypt-then-MAC lets the receiver verify the MAC without touching the cipher first. The MAC is computed over the ciphertext, so the receiver recomputes it over the ciphertext it just received, compares, and only decrypts if the comparison passes. Forged or tampered packets are rejected at the door, before the decryption key ever processes them. Hugo Krawczyk proved in 2001 that encrypt-then-MAC is secure for any secure cipher and any secure MAC, which is a much stronger guarantee than the other two orderings can offer.
How MAC-then-encrypt broke TLS
MAC-then-encrypt feels natural. You authenticate the real message, then wrap the authenticated bundle in a cipher. The problem is what the receiver has to do to check it. The receiver gets ciphertext, and the MAC is hidden inside that ciphertext, so the receiver has no choice but to decrypt first. Decryption is the cryptographic operation that happens before verification. That is the doom condition exactly.
With CBC-mode ciphers, decryption involves removing padding that was added to round the plaintext up to a block boundary. If the padding is malformed, the receiver behaves differently than if the padding is valid: a different error, or a different amount of work before the error. That difference is a padding oracle. Serge Vaudenay described the attack in 2002. An attacker who can submit modified ciphertexts and watch how the server reacts can recover the plaintext one byte at a time, without ever knowing the key.
Why this is so dangerous: A padding oracle does not break the cipher. AES is untouched. The attacker recovers plaintext purely from the receiver's observable reaction to decrypting forged data. The vulnerability lives in the ordering, not in any primitive.
The TLS designers tried to close the oracle by making the error responses identical. That moved the leak from the error message to the clock. The 2013 Lucky Thirteen attack measured tiny timing differences in how long the MAC check ran depending on how much padding was removed, and reconstructed plaintext from the timing alone. Years of patches followed, each one papering over a leak that existed only because verification happened after decryption instead of before it.
The two fixes the industry actually adopted
Encrypt-then-MAC as a retrofit
RFC 7366, published in 2014, added an encrypt-then-MAC extension to TLS so that existing CBC cipher suites could authenticate the ciphertext instead of the plaintext. With the MAC over the ciphertext, the server rejects tampered records before decrypting, and the padding oracle disappears because there is no decryption of attacker-controlled data to observe. It was a correct fix, but a retrofit onto a protocol that had shipped the wrong order for over a decade.
AEAD as the permanent answer
The durable fix was to stop asking engineers to wire a cipher and a MAC together by hand. Authenticated encryption with associated data (AEAD) bundles confidentiality and integrity into a single primitive with one interface. AES-GCM and ChaCha20-Poly1305 are the two in common use. There is no separate MAC step to misorder, because the construction handles authentication internally and is designed so that verification gates decryption.
TLS 1.3 took the strongest possible position: it removed CBC cipher suites entirely and permits only AEAD constructions. The protocol no longer offers a way to get the order wrong, because the order is no longer a choice the implementer makes. That is the cleanest expression of the lesson. When a class of bug comes from a decision, the most reliable fix is to remove the decision.
What this means when you read a system's design
The doom principle is a fast diagnostic for evaluating any protocol or library that handles encrypted messages. Two questions cover most of it:
- Is the MAC computed over the ciphertext or the plaintext? Ciphertext is the answer you want. It means the receiver can reject forgeries before decrypting.
- Does the receiver verify before it decrypts, with no observable difference in behavior between a failed MAC and a malformed plaintext? Any branch, error, or timing gap that depends on decrypting unverified data is a potential oracle.
In practice the cleanest answer to both is to not roll the combination yourself. Use a vetted AEAD construction through a library that has been reviewed, and let the single primitive enforce the ordering for you. The same reasoning runs through everything we build at Haven: AEAD ciphers for symmetric encryption, audited implementations rather than hand-assembled cipher-and-MAC pairs, and a strong default bias against any code path that processes data before it has been authenticated. The doom principle is old, but the failure it describes still ships in new systems whenever someone decides the order is just a detail.
Originally published at havenmessenger.com
