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.