Does AES-CBC always use PKCS#7?

I need to add AES decryption with a 256 bit key to our software, and of course I won't do it myself; rather, I chose a library that works fine for our needs. It supports various modes of operation, the one I need is CBC (I know GCM would be preferable, but we get data from older hardware, and this is what it uses. The hardware will get an update in a few years...).

However, the library always (like, there is no way to change it, it is hardcoded in the encryption and decryption routines) uses PKSC#7 for padding. Does AES-CBC always use this padding, or is it just a shortcut by the library because PKCS#7 is so ubiquitous with this algorithm that it has become a de-facto standard, and it is not conceivable to use anything else at this point?

Does AES-CBC always use PKCS#7 padding?

No. Other common or plausible paddings include

• No padding, where the plaintext's length is known to be a multiple of 16 bytes.
• Bit padding, where the plaintext is considered a bit stream, it is appended a bit at 1, then 0 to 127 bits at 0 to reach a block boundary. With big-endian bytes, that's appending a byte at 0x80 then 0 to 15 byte(s) at 0x00.
• Zero padding (same as above without the initial 1), suitable when what uses the the plaintext is known to ignore extra zero bits, as is often the case for compressed audio/video/image.

Among paddings I have heard of in the past (but never consciously met in combination with AES), there are ESP padding and CipherText Stealing. Others know more.

An AES-CBC library can be used to obtain encryption with no padding, even if it is hardwired for one particular, by submitting plaintext of length multiple of the block size and removing the last block of ciphertext.

Such library with hardwired padding can also be coerced to ignore the padding on decryption. That's easy if the library is designed for on-the-fly decryption: just don't tell it that the end of input is reached. Otherwise, an option is to use the library in encryption mode to encipher an empty plaintext with the same key, take the 32-byte resulting ciphertext $$C'_0\mathbin\|C'_1$$ (where $$C'_0$$ is the IV, zero will do) then after the last block $$C_k$$ of the actual ciphertext append an extra block $$C_k\oplus C'_0\oplus C'_1$$ before using the library for decryption. This will insure that the padding check passes, and yield a deciphered plaintext as with no padding.

And on top of encryption or decryption with no padding, it is easy to build any padding.

• Is any padding other than PKCS#7 common outside the smartcard world? May 12 '20 at 8:56
• @Gilles'SO-stopbeingevil': no padding and zero padding are used in industrial applications beyond smart cards, and supported by APIs including Java. Bit padding is common in hashes (MD5, SHAs), MACs, and encryption with DES. There are several variants of PKCS#7 padding (random or deterministic) and un-padding (at least two: one checks that the last byte $x$ is in $[1,b]$ where $b$ is the block size in bytes, the other treats byte $x$ as $((x-1)\bmod b)+1$; I can imagine there are other variants). ESP padding is yet another padding, I guess used.
– fgrieu
May 12 '20 at 9:39
• Bit padding is also used with AES sometimes in the smart card industry. @fgrieu I would include a mention of CTS in the answer; it isn't used much, but it is kind of special. May 12 '20 at 12:34
• There is also another; put a byte like 0xFF then randomly fill the rest except 0xFF. May 12 '20 at 16:24
• Also, do you mean no_padding option in the paragraph starting An AES-CBC library c May 12 '20 at 16:27