I am writing a small program which uses AES. In testing it with wrong passwords, I get error prompts from Microsoft C# component saying "the padding is bad"; whereas I expect wrongly decoded texts. Do these errors come from the original AES spec or not?
AES in general does not specify that it should return a bad padding message. In fact, AES in general says nothing about padding. Padding schemes are external to AES. Therefore, the message you are getting is .Net specific.
That said, be careful with these messages, as they can lead to a padding oracle attack.
No, the AES block cipher specification doesn't list these errors because they are specific to the padding used for a specific mode of operation. The papers on AES and the FIPS 197 specification only contain the block cipher, not the modes of operation.
The NIST Special Publication 800-38A Recommendation for Block 2001 Edition Cipher Modes of Operation specifies ECB and CBC modes which require the use of padding or ciphertext stealing to make sure that the message is a multiple of the block size. This is a requirement for these specific modes of operation. It informally specifies bit padding, but that's not what the Microsoft class uses.
The padding method that Microsoft uses has been specified in PKCS#7, which specifies the Cryptographic Message Syntax. The PKCS#7 padding method that is specifies is little more than a footnote in that specification. It doesn't specify the unpadding method nor the possible error conditions.
Decryption of a complete block of data with a symmetric block cipher - such as AES - will always succeed: A block cipher always maps every one block of plaintext (out of all possible plaintext blocks) to precisely one block of ciphertext (out of all possible ciphertext blocks). The result of decrypting with a block cipher mode of operation that requires padding of the plaintext however may fail.
Block ciphers can only encrypt a block at a time. They have to be used as primitive within a block cipher mode of operation to be able to encrypt a variable amount of plaintext and to be secure. Block cipher modes of operation such as CTR can already encrypt plaintext of any size (up to a maximum). However, modes of operation such as ECB (insecure) or CBC are only able to encrypt a plaintext that consist of N-times the block size. To make a plain text of an arbitrary size form an N-number of blocks, a padding algorithm must be used.
This padding could be any one of a set of known padding algorithms. Usually however PKCS#7 padding (sometimes also called PKCS#5 padding) is used. This is a deterministic scheme in the sense that the unpadding is completely independent of the contents of the plaintext. Microsoft uses this padding / unpadding mode by default for ECB and CBC.
If the ciphertext was mangled or if the incorrect key was used then then the decryption of the last block - if affected - will contain random data. It therefore likely result in a block that contains invalid padding. When this occurs the implementation generates an error / exception.
In CBC mode an incorrect IV may also result in incorrect padding for short plaintext / ciphertext (plaintext smaller than 16 bytes).
As the unpadding algorithm is fed random data, there is a small but significant chance that the unpadding does not detect an error. The chance of this happening is slightly higher than 1/256 for PKCS#7 padding, because there is about a 1/256 chance that the result ends with
01. In that case no error is raised and an incorrect plaintext is returned.
- CBC mode padding oracle attacks try to detect the error or exception. They use this information to retrieve the plain text without performing any attacks on the block cipher itself - and they are entirely practical.
- It is best to perform integrity checks and add authentication (HMAC, MAC or an authenticated mode of operation) to prevent padding oracle attacks. This will make sure that you will always get an error or exception if the incorrect ciphertext or key is used; that way you will always receive the correct plaintext after unpadding.