How does Java surface padding errors during decryption, and why is exposing BadPaddingException dangerous (padding-oracle)?

## How decryption can fail in Java When you call `cipher.doFinal(ciphertext)` to decrypt, several distinct failures can occur, each with its own exception: - **`IllegalBlockSizeException`** — the ciphertext length is not a multiple of the block size (for a block mode without padding), so it can't be processed at all. - **`BadPaddingException`** — the bytes decrypted fine structurally, but the **padding** at the end is not valid PKCS#5/PKCS#7. This is the cipher telling you 'the last block's padding bytes don't form a legal pattern'. - **`AEADBadTagException`** — for AEAD modes like GCM, the **authentication tag** didn't verify. It is a *subclass of `BadPaddingException`*, which lets old code that catches `BadPaddingException` still catch tag failures. - **`InvalidKeyException` / `InvalidAlgorithmParameterException`** — thrown earlier, at `init`, for a bad key or bad/missing parameters. ## What PKCS#5/PKCS#7 padding is CBC needs the plaintext length to be a multiple of 16 bytes. PKCS#7 padding fills the last block by appending N bytes each equal to N (if 3 bytes are needed, append `03 03 03`; if the data is already block-aligned, a full extra block of `10 10 ... 10` is added). On decrypt, the cipher reads the last byte to learn N and checks that the final N bytes all equal N. If they don't, it throws `BadPaddingException`. ## The padding-oracle attack This validation is exactly what an attacker can weaponize. A **padding oracle** is any observable signal that tells the attacker whether a submitted ciphertext decrypted to *valid padding* or *invalid padding*. The signal can be: - A different **exception/error message** ('bad padding' vs 'internal error'). - A different **HTTP status** (500 vs 200, or a different error page). - A measurable **timing** difference (validating padding then a MAC vs failing early — the Lucky-13 / BEAST-era class). Given such an oracle, an attacker who *cannot* read the key can still **decrypt CBC ciphertext one byte at a time**. The math: because CBC XORs the previous ciphertext block into the decrypted block, the attacker tampers with the previous block's bytes and watches the oracle to discover which value produces valid padding; that reveals the intermediate decryption byte, and XORing with the original ciphertext byte yields a plaintext byte. Repeating across positions and blocks recovers the whole message. Real CVEs in this family include the original Vaudenay padding oracle, POODLE, and Lucky 13. ## Defenses (in order of strength) 1. **Use authenticated encryption (AEAD).** With `AES/GCM/NoPadding`, there is *no* CBC-style padding and the tag is verified first; a tampered ciphertext fails with `AEADBadTagException` before any plaintext is exposed. This eliminates the entire padding-oracle class. **This is the real fix.** 2. **If you must use CBC, use Encrypt-then-MAC.** Compute an HMAC over the ciphertext (and IV) and verify the MAC *before* decrypting. If the MAC fails, you never run padding validation, so there is no padding signal. Verify the MAC in **constant time** (`MessageDigest.isEqual`). 3. **Uniform error handling.** Catch all decryption-related exceptions and return one **generic** error to the caller — same message, same status code, same response shape — for bad padding, bad MAC, bad key, anything. Never let the *type* of failure leak. 4. **Avoid timing leaks.** Don't branch into expensive work only on the success path; aim for constant-time-ish handling so an attacker can't distinguish failures by latency. 5. **Don't log specifics to the client.** Detailed exception types belong in server-side logs (for ops), never in responses. ## Practical guidance for Java code ```java try { byte[] pt = cipher.doFinal(ct); // use pt only here } catch (AEADBadTagException | BadPaddingException | IllegalBlockSizeException e) { // single generic outcome; log internally, return uniform error externally throw new DecryptionFailedException("decryption failed"); // no detail leaked } ``` Note that catching `BadPaddingException` already catches `AEADBadTagException` (subclass). The key mental model: **the cipher gives you precise failure types so you can debug — but you must collapse them into one indistinguishable outcome at any trust boundary**, and you should prefer GCM so padding errors don't exist in the first place. With this, a reader can name each decrypt exception, explain how PKCS#7 padding validation creates an oracle, describe the byte-at-a-time CBC attack at a high level, and list the defenses ending with 'just use AEAD'.