Why verify padding at all?

Question

Whenever a ciphertext is decrypted using a block-cypher, we need to remove the padding. There are different ways to add padding, but they usually set the last byte of the last block to the number of padding bytes that were added and need to removed (e.g. we added 5 bytes, so we set the last byte to 0x05).

My question is: why do we need to verify padding? Why not read the last byte, remove that many bytes from the message, and be done with it?

Emitting a padding error sometimes catch integrity problems, but opens one to attacks like Padding Oracle, which is able to retrieve the entire plaintext in certain situations. It seems to me this is a terrible trade-off. What's the reasoning behind padding verification?

Answer 1

First of all, a more usual padding scheme would add 5 times the same byte 0x05 (in your example) so the check not just removes 5 bytes, but also checks that the 4 bytes before it have the same value. But let's assume your scheme (which is underspecified: what to put in the bytes before? Zeroes, or random values?) for now.

What if you cannot remove that many bytes? Do you allow for final bytes that exceed the block length (so remove more than one block)? (TLS does do this.) Do you just discard the data? But that's also observable, probably. And if the length of the final output is somehow observable, you leak the final byte of the last block which could also be used for a padding oracle style attack.

In general, use a cryptographic MAC to protect your ciphertext, and verify it first. Emit those errors. Then padding errors should not occur at all.

Answer 2

Your suggestion is essentially what ISO 10126 does, since there's no way to verify the random bytes that make up the rest of the padding. You could do the same with e.g. PKCS #7 padding, as you suggest.

However, this would leave a covert channel. If those other padding bytes are not verified, they can be chosen by the sender and even modified by an attacker if the encryption is sufficiently malleable. (Think about a malicious encryption library that leaks e.g. key bytes in the padding part of the ciphertext. Quite convoluted, perhaps...)

The scheme would still allow a padding oracle attack on the last byte of every block, if the padding is only allowed to be one block or required to be shorter than a <256 byte message. Either would allow one to find a minimal byte value for which the padding is incorrect. Thus, you'd need to authenticate the ciphertext if such an attack was possible, just as with fully verified paddings.

Since both encrypt-then-MAC and secure non-CBC modes solve the problem for good, there is IMO little use tweaking the padding, especially to only mitigate the attack.