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.