Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Depending on the framework you are using, there are various padding modes that can be used with AES encryption. For example, with .NET we can choose PKCS7, ISO10126, ANSIX923, Zeros or None.

I understand that the encryptor and decryptor need to use the same mode to be interoperable.

What considerations are there when choosing a padding mode? With the exception of 'None', does it even matter which you choose? Can some be considered more secure than others?

share|improve this question
There is one use case (for ECB/CBC block modes) where padding is not required and that is when the length of the plain text is known. For instance, if the contents of the message are BER/DER encoded, then the length is specified in the message itself. In that case, it can be harmful to unpad the message since the type of padding may change in the future. Otherwise you will need padding to distinquish between the plain text and the added bytes at the end. – Maarten Bodewes Dec 17 '11 at 9:40
up vote 11 down vote accepted

Padding None can be used with stream cyphers and AES-CTR in order to keep the cyphertext the same length as the plaintext. Padding Zeros cannot always be reliably removed, and so should be avoided. Any of the others can be reliably removed and are fine for use.

Padding None leaks information about the length of the plaintext. Apart from that there is no security implication in the choice of padding. All padding gives the attacker is a partial insight into the contents of the last block. In effect this is a known plaintext attack. If the cypher can't resist a known plaintext attack then the problem is with the cypher, not the padding.

share|improve this answer
All padding schemes leak some information about the length of the plaintext (unless all possible plaintexts are shorter than one padding block), None just leaks more of it. One should also beware padding oracle attacks; the best way to avoid them is to encrypt-then-MAC, but in any case it's a good idea not to try to verify the validity of padding. – Ilmari Karonen Dec 16 '11 at 16:14
Note that padding oracle attacks are very likely when the attacker can validate if the padding is correct if the oracle is readily available to them. It depends on the use case, but I think they are more common than most people would expect. Use cases may change in time as well, so not being vulnerable now does not guarantee safety in the future. You could also use a scheme like AES in EAX mode to provide integrity/authentication of the cipher text. The only trouble with that is that EAX is not as commonly available as other MAC modes (but it requires only one key). – Maarten Bodewes Dec 17 '11 at 9:35
@IlmariKaronen Reviewing this answer: not checking the padding is not really an option, because it would return a plain text string with an unknown length, and you will likely run into other known plain text problems later on. See the papers/blogs on XML encryption on this. The only option you have is to add integrity checks for online protocols. Futhermore, whatever you do, it's likely that you will leak timing information. – Maarten Bodewes Jan 7 '12 at 1:15

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.