8

How can I remove the padding from a decrypted string? I'm using RijndaelManaged provider to encrypt and decrypt. When I decrypt there are several /0/0/0/0/0/0 at the end of the string. My question is how can I gracefully (properly) remove the characters from the result string?

Greg
  • 23,155
  • 11
  • 57
  • 79
Hcabnettek
  • 12,678
  • 38
  • 124
  • 190
  • How are you decrypting the data? Does Rijndael pad cleartext? – R. Martinho Fernandes Mar 10 '11 at 22:11
  • 1
    @Martinho Fernandes - Rijndael encrypts data in blocks of constant size (typically 128, 192, or 256 bits). Getting to and from those block sizes requires a higher level protocol. – Jeffrey L Whitledge Mar 10 '11 at 22:13
  • Roundtripping with Rijndael does not produce a different output from the input. MSDN has a [sample](http://msdn.microsoft.com/en-us/library/system.security.cryptography.rijndaelmanaged.aspx) showing how to use Rijndael to encrypt and decrypt data that transparently uses the padding you set as detailed in [this answer](http://stackoverflow.com/questions/5266494/rijndaelmanaged-decryption-how-can-i-remove-the-padding-0-gracefully/5266556#5266556). – R. Martinho Fernandes Mar 10 '11 at 22:44
  • @Martinho Fernandes - I was referring to "Rijndael" the encryption algorithm as specified by NIST. You were referring to "Rijndael" the .NET Framwork class. In this case, the framework is supplying the "higher level protocol" that I mentioned. – Jeffrey L Whitledge Mar 10 '11 at 22:52
  • @Jeffrey: Sure. But I was referring to the algorithm as well. It requires the input to be a multiple of a certain number. You do the padding. But whatever it is you feed it upon encryption is what you get upon decryption right? – R. Martinho Fernandes Mar 10 '11 at 22:55
  • @Martinho Fernandes - Yes, the decrypted octets are exactly the same as the encrypted octets. But something somewhere must get the data to the right length for Rijndael to work its magic on, and that padded length will be what comes out of the decryption. – Jeffrey L Whitledge Mar 10 '11 at 22:58

4 Answers4

11

You are most likely not using the correct padding and block modes of the RijndaelManaged instance (called provider in the code below). Since the symmetric encryption providers in .NET are all block ciphers, these settings affect how padding works (as well as how secure the output will be).

The settings below will give you the best security when using RijndaelManaged:

// set the padding algorithm
provider.Padding = PaddingMode.ISO10126; // default is PKCS7
// set the block chaining mode
provider.Mode = CipherMode.CBC;

If you are not the one encrypting the data and you cannot figure out which settings the originating party used then you'll find help in some of the other answers :)

Morten Mertner
  • 9,414
  • 4
  • 39
  • 56
  • +1 I was not aware of this information, is there any chance you can cite why this is best? – Chris Marisic Aug 09 '11 at 12:45
  • 2
    CipherMode.CBC essentially ensures that two identical input blocks do not result in the same encrypted output, which improves security (see http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation). The downside of CBC is that an IV is needed and execution needs to be sequential. – Morten Mertner Aug 15 '11 at 10:41
  • 2
    PaddingMode controls what characters are used to fill the last chunk of data up to block size used. The default is (afaicr) 0s, which is less secure that randomized data. Check the MSDN documentation for CipherMode and PaddingMode, as I recall they contained all of this information. – Morten Mertner Aug 15 '11 at 10:44
5

By using TrimEnd() like this:

theString.TrimEnd("/0");
Greg
  • 23,155
  • 11
  • 57
  • 79
Arnaud F.
  • 8,252
  • 11
  • 53
  • 102
  • 2
    Since a null character is legal in a .NET string, I would personally consider this to be an improper method. – Jeffrey L Whitledge Mar 10 '11 at 22:15
  • 1
    @Jeffrey: worse is, this is not a null character. This is a slash followed by a zero, which is sort of "legaler". Oh, and it doesn't compile because TrimEnd takes an array of chars. – R. Martinho Fernandes Mar 10 '11 at 22:26
  • 5
    I'm guessing you meant `theString.TrimEnd('\0');`, which trims null characters from the end of the string. Unless the decrypted string really is padded with alternating slashes and zeros. – Greg Mar 10 '11 at 23:02
1

You could prefix the length of the string to the beginning of the string before encrypting them both, then, after decrypting, use the length to determine where the string ends.

Or you could base64 encode the string before encrypting it, then decode it afterwards.

Or encode it using a binary or XML serializer before encrypting it.

All of these methods have the advantage that they allow you to recover exactly the string that was stored. Any method that takes the current output and guesses at what transformation to apply does not have that property.

Jeffrey L Whitledge
  • 58,241
  • 9
  • 71
  • 99
  • 1
    You're right, but even easier is to just one of the correct [padding modes](http://msdn.microsoft.com/en-US/library/system.security.cryptography.paddingmode%28v=VS.80%29.aspx). – President James K. Polk Mar 12 '11 at 01:31
0

I don't see what it has to do with encryption. IIUC you're already done decrypting and have a plaintext string that has something at the end you want to remove. If so, your question is about string manipulation and it's irrelevant what encryption algorithm you're using. But maybe I misunderstood..?

Suggestion (probably not correct, but you'll get the idea):

string pattern = (i % 2 == 0? "/0" : "0/");
var sb = new StringBuilder(s);

int i = s.Length - 1;
while (sb[i] == pattern[i % 2]) --i;
sb.Length = i;
s = sb.ToString();
The Dag
  • 1,811
  • 16
  • 22
  • The question may not be about *encryption* exactly, but the problematic string of events appears to be `original string` -> `encryptiong process` -> `corrupted string` , so it is about fixing the encryption process. – Jeffrey L Whitledge Mar 10 '11 at 23:22
  • 1
    A block cipher has a block size, 16 bytes in the case of Rijndael. It only work in chunks of 16 bytes. If you have less then that you have to pad the data out to be 16 bytes exactly. It sounds easy, and it is, except that the when that block is decrypted the result is 16 bytes. Now it is possible that some of those bytes are "real" data and some are padding. There needs to be some way for the decryptor to know. – President James K. Polk Mar 12 '11 at 01:40