Rijndael algorithm (Right side 8 bit padding issue)

We are creating sample application for windows mobile using Rijndael algorithm.开发者_JAVA技巧 Its working fine. But the problem is when we decrypt the data there is a 8 bit padding up on the right side of the value for the example, we are encrypting a Unique key for transaction and it looks like this :

Before encryption: MI03112009044625000000000000008024754008

After Decryption: MI03112009044625000000000000008024754008揞⑁㋬㓠⥳空⠜資

can anyone help on this right padding happening in the original value.

Code: Encryption:

byte[] inputData = System.Text.Encoding.Unicode.GetBytes(inputDataString);           
MemoryStream stream = new MemoryStream();
CryptoStream cStream = new CryptoStream(stream, RijndaelAlg.CreateEncryptor(key, value), CryptoStreamMode.Write);
cStream.Write(inputData, 0, inputData.Length);           
cStream.Close();

Decryption:

MemoryStream stream = new MemoryStream(outputData);
CryptoStream cStream = new CryptoStream(stream, RijndaelAlg.CreateDecryptor(key, value), CryptoStreamMode.Read);
cStream.Read(outputData, 0, outputData.Length);
cStream.Close();
byte[] decryptedData = stream.ToArray();

return System.Text.Encoding.Unicode.GetString(decryptedData, 0, decryptedData.Length);

Is there any other solution for this? Because we cant get the original data length

Geetha

I think this is because you encrypting less than 48 bytes.

You can try that by encoding/decoding a clear-text that is say 42 bytes you'll have 2 fewer padding bytes.

Also, but that may depend on the particular block cipher you are using, deciphered data may systematically be a length that is a multiple of the block (which is 16 by default in AES, and typically in Rijndael).

Edit: "To allow padding or not to allow padding... that is the question!"
Many ciphers allow preventing padding in the last block (in some cases even the last block is only a few bytes in length!...) and this resolves the issue of finding the effective end of the message, for recipients that do not know the length of the message.
In the context of short messages, this could reduce the strength of the encryption, and the following two approaches may mitigate this:

• add a "salt" at the beginning or the end of the message (or both)
• add a terminator sequence (and use padding)
• add length information (and use padding)

Note: These suggestions are a bit tricky, in a sense that they, in of themselves, may too weaken the encryption, by introducing "cribs" which an attacker could use. For example if the length was systematically sent in the first 4 bytes of the message, and attacker could use this info for looking for the corresponding patterns in the ciphertext. Let's not get overly paranoid however, these short hints are difficult to leverage, especially when used in combination with "salt".

"SALT" is simply a [more or less] random sequence of bytes which are added somewhere in the clear-text (typically before or after it), and which is encoded as if it were part of the message. The receiving party then discard this salt from the clear-text produced by the decryption. A simple salt can be of fixed length, making its removal easier, it can also be of variable length whereby the length can be explicitly indicated somewhere within the salt or coded/hidden in more subtle and variable ways.

I got the solution to remove the extra padding in the decrypted data.

Code:

this.algorithm.Mode = CipherMode.CBC;
protected SymmetricAlgorithm algorithm;
ICryptoTransform cryptoTransform = this.algorithm.CreateDecryptor();
CryptoStream cryptoStream = new CryptoStream(memoryStream, cryptoTransform, CryptoStreamMode.Write)