After digging a little deeper into cryptography I am wondering what impact the different padding schemes do have an the security of an encryption algorithm. Lets take AES-128 in CBC mode as an example, because I am currently working with this one.

Wikipedia lists several padding schemes but does not mention anything about the security impact of choosing one of them. The library I am currently working with supplies PKCS5 padding, which is not even mentioned in the Wikipedia article. There are obviously several more padding schemes out there.

I am not an expert in cryptography, so maybe I am totally wrong, but I cannot see how the different padding schemes should have a significant impact. Am I basically free to choose one and be happy or are there some things I have to consider?

2 Answers 2


Short answer: Don't sweat it. In most cases, the choice of padding method doesn't matter.

Longer answer: why it doesn't matter. As long as you use proper crypto design practices -- in particular, as long as ciphertexts are properly authenticated -- I'm not aware of any way that the choice of padding affects security (with one exception, see below).

It's true that if you fail to authenticate the ciphertexts, then there can be attacks, as @Thomas explains. Then again, if ciphertexts are not properly authenticated, you've probably got a host of other problems, so you shouldn't blame this on the padding scheme. Cryptographers know that if you encrypt something, you really should be authenticating the ciphertext; failure to do so is a classic rookie mistake that can open up serious security flaws.

In short, if you're following good crypto practices, the choice of padding shouldn't matter much for security (and if you're not following good crypto practices, you may have bigger problems).

The exception: a case where it does matter. OK, now we're down to the fine print. This is where I admit that the above is a bit of an oversimplification. There is one situation where the choice of padding may be very important to security: resistance to traffic analysis.

Encryption does not conceal the length of the messages being encrypted: the encrypted message typically reveals the length (or approximate length) of the message that was encrypted. In some contexts, this can be highly problematic. For instance, there are contexts where revealing length information gives away the entire store: it reveals the stuff you were trying to keep confidential. (See, e.g., Chen et al's astonishing side channel attacks on SSL-encrypted web applications. Among other things, they showed that an eavesdropper who observes the lengths of network packets while the user is typing in a web search query can infer what the search query was. I think Google fixed the problem, but it was a stunning, eye-opening example of a general risk that was previously known.)

If you are in a context where message lengths reveal sensitive information, then you have a problem. The standard defense is to pad the messages before encryption, so that the ciphertext length does not reveal anything about the message lengths. One way to do this is to pad all messages out to a fixed length, before encrypting. Another (less secure) way to do it is to add padding of a random length, with enough random padding that the random noise obscures the signal and prevents an attacker from learning enough information about lengths to do any harm. So, in a context where we need to prevent traffic analysis, the design of the padding scheme becomes critical, and standard padding schemes are probably not going to be enough: you may have to do something special.


There can be some issues with padding:

  • A random padding can be used for some kind of steganography, allowing a corrupt sender to leak secret data for usage by third parties. This is not a great concern in normal situations, but it still looks bad.

  • There have been some attacks on padding handling. Namely, the receiver could decrypt and find a valid padding, or some random-looking junk. If the receiver reports a distinct error code in the latter case, then this is a "padding oracle" and it can be used to attack the system. This has been explained at length by Vaudenay in 2002 and was the basis of the ASP.NET padding oracle attack eight years later.

Padding-less encryption modes (e.g. CTR) avoid the complexity and network overhead of padding.

You must log in to answer this question.

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