AES Padding (Nullbytes vs PKCS7)

Question

I currently implement the AES(128,192,256)(ECB,CBC). Does the type of padding affect security? I just want to fill the blocks with null bytes.

Answer 1

Padding

You cannot fill the remaining blocks with the null bytes unless

• The message has a fixed size that doesn't require sending file sizes.
• The file size is sent over the channel.
• The message doesn't contain null-bytes.

In the general, the padding must be unambiguous. 10..0 padding can be fine.

• if data is 1234567890000000

  now the data is 123456789 or 1234567890 or 12345678900 or..

• if you use 10..0 then with the data 1234567890001000

  it will be clear that the data is 123456789000

You can use PKCS#7 padding for ECB and CBC mode. PKCS#7 supports modes have block sizes larger than 64-bit block up to 255. The previous one, PKCS#5 padding had support up to 64-bit block size that was fine for DES.

In PKCS#7 padding, the remaining bytes count is padded as a byte value. For example;

123456789ABCDEF1     here consider the integers as bytes like 1 = 0x01
123456789ABCDE22
123456789ABCD333

Then the removal of padding bytes result in

123456789ABCDEF
123456789ABCDE
123456789ABCD

If the last block is full an additional block is filled with 1F

0123456789ABCDEF next block is full of `1F`s

• The known padding methods are not limited to the above methods see more in Wikipedia: Padding_(cryptography).
• For the complete difference between PKCS#5 and PKCS#7 see this canonical question What is the difference between PKCS#5 padding and PKCS#7 padding

CBC padding Oracle attack

For CBC mode operation, if padding oracle is applicable then the server can act like a decryption oracle. This attack academically first published in 2002 by Serge Vaudenay. Although the servers are patched there are attacks based on the downgrade like Lucky13 and Poodle. Keep your servers on the secure level! TLS 1.3 has huge clean ups and it has no more CBC mode of operation. The TLS 1.3 encryption modes with their IDs;

• {0x13,0x01} - TLS_AES_256_GCM_SHA384
• {0x13,0x02} - TLS_CHACHA20_POLY1305_SHA256
• {0x13,0x03} - TLS_AES_128_GCM_SHA256
• {0x13,0x04} - TLS_AES_128_CCM_8_SHA256
• {0x13,0x05} - TLS_AES_128_CCM_SHA256

One can see how the padding oracle attacks work in these answers and remember if applicable the attacker can decrypt all of the message not only the padded part.

• If there is no such padding oracle attack then it is secure. Example the data stored as data-at-rest.

Padless modes

It is better to use a mode like CTR and OFB modes that don't require padding at all. They can work with arbitrary byte sizes.

Forget ECB

Don't use ECB which is insecure leaks patterns, it is not a probabilistic encryption, not even secure against KPA attacks on multi-block messages. Some even don't call it as a mode of operation.

Modern Modes

The all above modes are also called archaic mode of operation and they can have at most CPA. In modern Cryptography, we use and suggest to use Authenticated Encryption (AE) (AEAD: AE with associated data) modes like AES-GCM and ChaCha20-Poly1305 which can have IND-CCA2. These will provide you Confidentiality, Integrity, and Authentication, all in one. And remember, never use a key-IV pair again in these modes. If you want only leak about the same message is sent nothing more then use a misuse-resistant mode like SIV. AES-GCM-SIV will be the future.

There is a new mode

Daence: Salsa20 and ChaCha in Deterministic Authenticated Encryption with no noNCEnse as of 2020 by Taylor R Campbell

We present Daence, a deterministic authenticated cipher based on a pseudorandom function family and a universal hash family, similar to SIV. We recommend instances with Salsa20 or ChaCha, and Poly1305, for high performance, high security, and easy deployment.

This mode uses the Associated Data (AD) to eliminate the case that even the same message is sent under the same key-IV pair if the AD is different than the ciphertext messages will be different up to some probability.