Is there any security gain / risk by adding additional padding (beyond what is required) when using AES-256 to encrypt very short strings?

Question

I would like to encrypt some authentication tokens using AES 256 (not tied to this algorithm but it seems to be a reasonable choice). These messages are usually very short at 128-256 bits. I'm concerned foremost about the security, not very concerned about ciphertext length or performance in either encryption or decryption. These are shared secrets so I have to be able to obtain the plaintext.

I am curious if any additional padding beyond what is required for the message to match the blocksize is beneficial.

To clarify this is not a question about padding the message so that it can be run through the encryption algorithm, but rather would I gain anything by padding to the message to say 1024 bits vs. 256 when the message is very short. I am already using an IV as I am reusing a key.

If I do pad to an additional length should I just use a single character, or should I put in a random stream of data?

My concern is that by only padding to 256 bits I may potentially betray the size of the secret (although most of them are shorter then the blocksize).

Answer 1

Longer padding has no disadvantages security wise and the advantage is that it leaks less information about the length of the plaintext. The only downside to more padding is the larger ciphertext size, so as long as you consider the overhead acceptable padding to a larger block size is a good choice. For example in a chat application I'd pad to multiples of 256 bytes or even larger blocks.

In principle any padding works fine, as long as you can unambiguously remove it. I recommend deterministic padding instead of randomized padding, it simplifies testing and avoids concerns about covert channels. A proper IV already adds all the randomness you need, and AES is assumed to be secure against known plaintext attacks.

Typical paddings are 0x80 followed by as many 0x00 as you like, or as many 0x00 as you like, followed by the length of the padding or the length of the plaintext. Just a single byte doesn't work, since you can't know if a byte is still part of the padding or already part of the message.

---

As always, remember to use an authenticated mode of encryption with a proper per-message IV. AES-GCM is popular, but the conventional choice of AES-CBC combined with HMAC in encrypt-then-MAC order is fine as well, if you manage to implement it correctly.

Answer 2

There's a security gain, and it is just what you mentioned.

If an attacker knows that the different lenghts of cyphertext mean something, he doesn't need to decrypt the message.

The most extreme (textbook) situation is when you have N messages, and each has a different length. If the attacker knows what each of those message mean, he can deduct the type of message, but still miss some details. This is still a security flaw, as the attacker can infer something from the message, while (good) cryptography should not reveal anything the attacker didn't know before looking at the cyphertext.

On the risk side, as long as you don't use ECB mode, you should be ok.

Answer 3

Additional padding does not necessarily increase the security in this scenario. It just increases the decryption time. You are not performing any other operations on the padded input before sending it through the algorithm for encryption. If you employ a custom protocol performing additional operations on the plain text and using the aes algorithm, there could be an increase in security. (Please dont try that since custom protocols are almost always easily breakable until unless endorsed by Cryptanalysts)

You should also consider Padding oracle attacks. As long as you are not using any standardized padding scheme and use random bytes for padding, you could overcome this attack.