A service decrypts attacker-supplied ciphertext and returns one error for "bad padding" and a different one for "bad content." Explain the general class of attack this enables, and state the ordering rule for encryption and authentication that prevents it.

## What an oracle is An *oracle* is any interface that answers a question about a secret. The attacker does not need it to answer "what is the plaintext?" — a single bit of feedback per query is enough, provided that bit depends on the decrypted data and the attacker can query repeatedly. The service in the question is a textbook one: it decrypts whatever the attacker sends and behaves differently depending on whether the decrypted bytes had valid padding. It has thereby delegated a secret-dependent decision to an untrusted party. ## Why the padding case is so powerful Block modes that need whole blocks pad the final block with a deterministic, self-describing pattern (for instance, *n* bytes each of value *n*). Decryption strips the padding and rejects the message if the pattern is not well-formed. In CBC, each plaintext block is the block-cipher decryption of the ciphertext block, XORed with the *previous* ciphertext block. The attacker fully controls that previous block. So they can take a target block, prepend a block of their own choosing, and vary it until the service stops complaining about padding — which tells them that the last byte of the intermediate value XORed with their chosen byte equalled `0x01`. That one equation gives them the intermediate byte, and the intermediate byte plus the *real* previous ciphertext byte gives them the real plaintext byte. Move to the next byte, target `0x02 0x02`, and repeat. About 128 queries on average per byte; no key, no cryptanalysis. And because they now know the intermediate values, they can *also* encrypt arbitrary plaintext of their choosing. ## The general lesson, which is bigger than padding Padding is the classic instance, but the class is broader. Any of these is an oracle: - a distinguishable error code or message ("malformed" versus "unauthorized") - a timing difference, because the code path after a successful unpad does more work - a difference in response size, or in whether a subsequent request succeeds - a side effect — a log line, a metric, a retry, an email, a row written - a difference visible only to the attacker as a *behaviour*, such as a connection being closed early So "return the same error message" is a fix on the *detection* rung, not the structural one. Attackers who lost the error text have historically switched straight to timing. The invariant to state in an interview is: **no value derived from an unauthenticated ciphertext may influence anything the attacker can observe** — not the response, not the timing, not a side effect. The only way to honour that is to establish authenticity *before* decrypting. ## Composition order Three ways to combine an encryption scheme and a MAC: **Encrypt-then-MAC.** Encrypt the plaintext, then compute the tag over the ciphertext — including the IV/nonce and any unencrypted header such as a version or key identifier. On receipt: check the tag first and abort on failure without invoking the cipher at all. This composition is *generically* secure: if the encryption is IND-CPA and the MAC is unforgeable, the result gives integrity of ciphertexts and hence chosen-ciphertext security, for any such pair. That genericity is the property you are buying — the security does not depend on happening to pick a compatible pair. **MAC-then-encrypt.** Compute the tag over the plaintext, then encrypt plaintext-and-tag together. To verify, you must first decrypt attacker-supplied data — which means running the cipher, stripping padding, and parsing, all before you know the message is authentic. This is precisely the shape that produces padding oracles. It is not universally insecure, but it is secure only for particular combinations and requires great care to implement without a timing side channel; that is an unattractive bargain when a generic construction exists. **Encrypt-and-MAC.** Encrypt the plaintext and separately tag the plaintext, sending both. The tag is a deterministic function of the plaintext, so identical plaintexts produce identical tags — an equality leak that undoes the randomization the mode provided. It also still requires decryption before verification. The practical conclusion: prefer a standard authenticated mode, which bakes the ordering in. If you must compose by hand, use encrypt-then-MAC, cover every byte that is not encrypted, and use a separate key (or properly derived subkeys) for encryption and authentication. ## Constant-time comparison Once you are verifying a tag, *how* you compare matters. A comparison that returns on the first differing byte leaks, through timing, how many leading bytes matched. An attacker who can measure that turns forging a 16-byte tag from an infeasible 2^128 search into roughly 256 attempts per byte — a few thousand queries. Compare tags with a fixed-time routine that examines every byte and accumulates the difference, and make the failure path indistinguishable from the success path in observable time and behaviour. This is the same principle as above, applied to the tag rather than to the padding. ## What the associated data must cover A correctly ordered construction still fails if the tag does not cover everything an attacker can influence. The IV/nonce, the key identifier, the format version, the record or row identifier, the tenant — if any of these travels in the clear and is not authenticated, it can be swapped. Authenticating the ciphertext but not the header means the attacker can redirect a valid ciphertext to a different record, or downgrade the version field to select a weaker parser. ## The ladder Structural separation: use an authenticated mode, or encrypt-then-MAC, so that unauthenticated input never reaches a parser. Escaping/transformation-equivalent: careful hand-built verification with constant-time comparison — correct in principle, but you now own the details. Validation: sanity-checking decrypted plaintext, which happens too late. Detection: uniform error messages and alerting on decryption-failure rates, which raises the cost of an attack without preventing it.