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?

up vote 3 down vote accepted

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.

  • Sorry if that was not clear, but I'm not specifying a new padding. I meant that ANSI X.923, ISO 10126 and PKCS#7 all end with the number of bytes added. – BoppreH Sep 8 '14 at 21:13
  • It still leaves the issue of leaking the final byte from the length... – Henno Brandsma Sep 8 '14 at 21:17

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.

  • Wouldn't that only reveal the block size, though? Anything smaller is valid and may truncate or expand the message with the random padding; anything larger gives an error (or not!). – BoppreH Sep 10 '14 at 3:30
  • @BoppreH, finding the last byte of the last block only revels the exact plaintext length. However, the attacker can truncate the ciphertext by one block, then repeat the same and find the last plaintext byte of each block. – otus Sep 10 '14 at 4:20

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.