If I have a payload of e.g. 8 bits and I want to encrypt it using AES 128, I will need to add some random padding to make the plaintext 128 bits long. Does this padding affect the security of AES?

  • 1
    When it's down to very small message sizes like a single byte, enumeration becomes very practical, so it's more important to know what attack modes is possible with your setup. A straight forward encryption may not be approperiate in many cases.
    – billc.cn
    Mar 9, 2016 at 14:20

2 Answers 2


Since AES is a block cipher with 128-bit blocks, it can, by definition, process only a 128-bit entry. To turn it into a system that can encrypt and decrypt messages of arbitrary length, then you need to use a mode of operation. Each mode has its own requirements. Most will require an IV which MUST NOT be reused (if you encrypted several messages with the same key, each message needs its own specific IV), and some modes have extra requirements (e.g. in CBC, it is crucial that the IV are selected randomly, uniformly, and in a way that cannot predicted by whoever chooses the data to encrypt).

Some modes also require "padding" in case the input message length is not appropriate in some way. Some modes can process input data of arbitrary length (e.g. CTR), while others need the data to have a length that is a multiple of the block length (e.g. CBC).

Most attack models that warrant encryption may easily be turned into active attack models, in which the attacker not only wants to inspect the data, but he also may modify the data. Thus, whenever you use encryption, you normally need integrity as well. Combining encryption and a MAC is a non-trivial task, so using a mode which combines both features is highly recommended. The most standard mode that combines encryption and MAC safely is, as of early 2016, GCM.

If you do everything correctly, then there is no additional issue with the input data being short. Short data is common in, e.g., SSH connections.

Note, though, that while encryption protects the data contents, it tends to leak the data length. Depending on the kind of data that you are sending, its length might reveal a lot of information to outsiders.

Don't use random padding. Random padding cannot be checked at the decryption side, because it can be anything. Random padding gives extra power to active attackers (in SSL/TLS, see the POODLE attack, which leverages random padding in SSL 3.0). Instead, if padding is necessary, use a deterministic padding that the receiver can check. A mode that does not require padding is preferable, because it is easier to process it correctly on the decrypting side (i.e. without leaking information when an invalid message is sent).

Summary: use GCM.

  • note that if you can't guarantee that you will not re-use the IV, there are always fully nonce misuse resistant authenticated encryption schemes (like GCM-SIV), but they don't support "streaming" (i.e. you need at least two full subsequent passes over the data).
    – SEJPM
    Mar 9, 2016 at 14:08
  • I suppose that if the OP wants to encrypt an 8-bit message, streaming is not an issue... More generally, with AEAD modes, the receiver should not process incoming data before verifying the MAC, so even with a one-pass mode, full streaming is not really feasible, unless data is split into records (as in SSL/TLS), in which case two-pass modes are fine. Mar 9, 2016 at 14:29

No, padding does not affect the security of AES.
It is commonly used in modes such as CBC, PKCS#7 padding is particularly popular.

However, if you need to pad your message, chances are you're doing something wrong.
First you can use CTR mode to get rid off the neccessarity to pad your messages and secondly you should use authenticated encryption (such as AES-GCM) anyways.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .