views:

326

answers:

2

Hi all,

We are creating sample application for windows mobile using Rijndael algorithm. 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

+1  A: 

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.

mjv
Thank You for the info. Have included the following code and it works perfectly now. int count = testval.Length - mdpoddet.CMPODDETID.Length; testval = testval.Remove(mdpoddet.CMPODDETID.Length, count)RegardsGeetha
Geetha
Is there any other solution for this? Because we cant get the original data length
Geetha
I got the solution by using paddingMode.None in both encyption and decyprtion
Geetha
@Geetha Do beware that encoding short messages without padding may weaken the encryption (i.e. facilitate some attacks on the key). This is particularly true when the encoded messages follow common patterns or file formats. One way to offset these issues is to add some "SALT" at the beginning of the message.
mjv
Can u please explain it(about adding salt)?
Geetha
@Geetha see my edit with info about "salt" and ideas to maybe keep padding by introducing either length info or a terminator sequence in the message (and hence allowing padding).
mjv
Thank you for your help.
Geetha
@Geetha: "about adding salt" I ( very much a beginner on this ) wrestled with what you are looking at, eventually figuring out minimum block length for Rijndael ( which was not given ) and then discovering that they gave 256 but only 128 worked, and so on. A standard padding scheme - called pkcs5padding - gives some standards. The one book I read that I trust, along with the source that I was using, gave that any encipher operation was always padded - which by my experience eliminates some subtle but hard to code away issues.
Nicholas Jordan
A: 

Hi all,

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)
Geetha