The strange case of the appended bytes

If you happen to encrypt a stream by coding in .NET, let's say, you could face the "strange case of the appended bytes". What is this?

Suppose you have the following code that comes from Microsoft: http://msdn2.microsoft.com/en-us/library/aa964697.aspx

Well, if you take the time to compile it, you will discover that the output (decrypted) file is of a "bunch" of bytes greater than the original one. Also, the output will be always a multiple of the choosen Rijndael block size (in the case above, a multiple of 32).

Why?

The problem is that the unknown Microsoft author simply put PaddingMode to "None" (see DecryptFile method).

The PaddingMode.None mode is really not a padding mode at all. If you specify PaddingMode.None, you're telling the cipher that you don't want any padding performed at all. In this case, you must ensure that you only attempt to encrypt data whose length is an even multiple of the block size. If the data doesn't meet this requirement, you will get an exception stating that this is the case. The PaddingMode.Zeros mode simply pads the data with enough zeros to cause the length of the message to be an even multiple of the block size. The problem with PaddingMode.Zeros is that it is not reversible on decryption. Suppose the cipher encounters data that decrypts with five zero bytes at the end of the message. Are there five bytes of padding or are there 4 bytes of padding and an actual zero byte in the original plain text? How would the cipher be able to know? It really can't tell. If you use the PaddingMode.Zeros mode, you must transmit the actual length of the data as part of the message so that when the data is decrypted, the decrypting party will know how many bytes of plain text there are so they can strip the padding from the decrypted message.

The PaddingMode.PKCS7 mode is more interesting. This padding mode fills out the last block of the message with a sequence of bytes, the value of each of which is equal to the total number of padding bytes. For instance, given a block size of 128 bits and a final block plain text value of [AA BB CC DD EE FF], the padding string would be "0A 0A 0A 0A 0A 0A 0A 0A 0A 0A". The 0A value indicates that there are 10 total padding bytes. The padded block would then look like so: [AA BB CC DD EE FF 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A]. In order to reverse this, the cipher simply examines the value of the last byte in the block, verifies that the appropriate number of bytes containing this value exist at the end of the message, and then removes the padding from the decrypted data. You may be wondering what happens if our data length is a perfect multiple of the block size. In this scenario, PaddingMode.None and PaddingMode.Zeros add no padding. However, in the case of PaddingMode.PKCS7, padding must be added because the cipher must be able to reverse even a no-padding situation. In this case, an additional block must be added to the plain text and the value of each byte set to the block size in bytes. In the case of a 128-bit block, a block containing [10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10] would be added to the end of the message.

So, in that case the example just works if one sets a meaningful padding mode. PKCS7 (which happens to be the default value!) is the correct choice.