21
$\begingroup$

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?

Improve this question
$\endgroup$
1
  • 2
    $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes ♦
    Dec 17, 2011 at 9:40

1 Answer 1

Reset to default
17
$\begingroup$

Padding None can be used with stream ciphers and AES-CTR in order to keep the ciphertext 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 cipher can't resist a known plaintext attack then the problem is with the cipher, not the padding.

Improve this answer
$\endgroup$
3
  • 3
    $\begingroup$ 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. $\endgroup$
    – Ilmari Karonen
    Dec 16, 2011 at 16:14
  • $\begingroup$ 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). $\endgroup$
    – Maarten Bodewes ♦
    Dec 17, 2011 at 9:35
  • $\begingroup$ @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. $\endgroup$
    – Maarten Bodewes ♦
    Jan 7, 2012 at 1:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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