Why is padding used in CBC mode?

Question

I am newbie to CBC crypto: When I try decrypt the cipher text to recover the plain text, things are not going smoothly as I face some issues in the decryption process with padding and not obtaining the plain text finally.

So I would like to know about why padding is used in this CBC method? Why is it not used in the ECB method? Should we pass padding for the decryption process?

Below are the cipher text and IV which I have used in my testing:

cipher text(hex) - 6d 25 1e 90 44 b0 51 e0 4e aa 6f b4 db f7 84 65

Initialization Vector(hex) - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Expected Plain text(hex) - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Could someone try this ciphertext and IV and share the results?

Key size: 16;

Key used in hex: 10a58869 d74be5a3 74cf867c fb473859

Answer 1

So, I'll answer the theoretical part of your question, since we need a key to address the practical part.

Why is padding used in CBC?

Blockcipher such as AES are encrypting blocks of a fixed given size only, we call it the "blocksize". So, what if your data is smaller than the blocksize ? An easy solution is to add what we call "padding" to your plaintext in order to have its size match the block size. So, padding is there to allow you to encrypt data smaller than the blocksize... But what if you want to encrypt something bigger than your blocksize?

That's where the mode of operations, such as CBC, come into play. Modes of operations are there to allow you to encrypt more data than the blocksize of your symmetric blockcipher.

But since those modes of operation are still using the underlying blockcipher to encrypt data, it means that they can only encrypt a multiple of the blocksize. So, if you have $4\ell$ bits of data to encrypt, for $\ell$ the block size of your cipher, then you're fine. But what if you have $4\ell+5$ bits of data? (I am assuming the blocksize does not divide 5.) Then you need to pad the data with $\ell-5$ bits of padding in order to end up with a multiple of the blocksize of data ready for encryption with your mode of operation.

There are multiple methods to pad data, which can completely undermine the compatibility of a given encryption program with others. The most used padding method in symmetric ciphers and mode of operation is certainly PKCS#7.

Worth noting

There exists methods to avoid padding, in order to avoid padding completely so the ciphertext is the same size as the plaintext, the most common of those methods is certainly the one called ciphertext stealing.

There also exists modes of operation, such as CTR, which do not need any padding.

Now, contrarily to RSA encryption for instance, padding in symmetric encryption does not add security.

Checking the padding upon decryption can allow to catch errors in the transmitted ciphertext, because of the avalanche effect, (depending on the mode of operation used), but can also lead to terrific padding oracle attacks.

As explained in that question, it is better to use a cryptographic MAC to protect your ciphertext, and verify it first before performing decryption or even padding checks. I also refer you to that legendary question, regarding the way one should MAC its data when using encryption.

About ECB

Actually ECB also encrypts only multiples of the blocksize, so you will also need padding or another method to have enough data to encrypt. However, you should not use ECB for the reasons pointed out there.

---

Regarding your practical problem

So, I've tried your values:

from Crypto.Cipher import AES
import binascii

key = binascii.unhexlify("10a58869d74be5a374cf867cfb473859")
iv = binascii.unhexlify(16*"00")

plaintext = binascii.unhexlify(16*"00")
ciphertext = binascii.unhexlify("6d251e9044b051e04eaa6fb4dbf78465")

ciph = AES.new(key, AES.MODE_CBC, iv)

test1 = ciph.encrypt(plaintext)
print("The ciphertext is what we expected:", test1==ciphertext)    

#We need to reset the cipher to get the correct IV
ciph = AES.new(key, AES.MODE_CBC, iv)

test2 = ciph.decrypt(ciphertext)
print("The recovered plaintext is what we expected:", test2 == plaintext)

and as you can see if you try it with Python and PyCrypto, it works but your ciphertext strangely differ from the actual value at offset 4, as pointed in the comment by fgrieu. The actual value is 69, not 90.

This error at offset 4 explains why you couldn't get the correct recovered plaintext, because of the avalanche effect, the whole AES block was being impacted by that little mistake.