views:

154

answers:

2

Hello,

First time poster here. Awesome community here. After endless hours of searching, I'm unable to figure out the answer to this problem I"m facing.

First and foremost, I'm no guru when it comes to encryption/decryption, cryptology, etc. I only want to go so far in this realm without getting lost. The primary framework I code on is .NET and I was asked to create an AES CBC implementation for C#, that can work on JavaScript and ActionScript 3. I've been successful with both but with JavaScript, I've ran into an issue.

I decided to use SlowAES AES implementation because it seems to be the most popular with the best interop.

Please see the following links regarding my issue...

Issue #9: http://code.google.com/p/slowaes/issues/detail?id=9

Basically my issue with SlowAES is, I cannot decrypt something correctly without knowing the length of the original, unencrypted text. This defeats the purpose right? I should be able to decrypt an encrypted string without needing to know the original string.

If I'm missing something, I would be grateful if pointed in the right direction. Thankfully, I'm okay because .NET AES implementation I've put together can decrypt what SlowAES encrypts, same with ActionScript 3's implementation.

At this point I would just like to have SlowAES decrypt correctly.

Updated

After following the help of Remus, I've determine that SlowAES is using PKCS5/7 padding scheme but does not remove it properly. Now my problem seems to be with C#, understanding Byte Arrays, etc.

I can see the last character in my decrypted text is '5' which is preceded by a '0'. This pattern continues 5 times. Now from what Remus said below, I'm supposed to subtract the decrypted string length by this number. But the pattern is '05', does that mean I double 5 making 10 then subtract 10 from my decrypted string length?

Also, what would be the easiest way of obtaining the number I need to subtract? I'm using the following to obtain the number currently:

Byte[] decryptedBytes = System.Text.Encoding.ASCII.GetBytes(decrypted);
Byte padLengthByte = decryptedBytes[decryptedBytes.Length - 1];
Char padLengthChar = Convert.ToChar(padLengthByte);
String padLengthString = padLengthChar.ToString();
Int32 padLength = Int32.Parse(padLengthString);

I'm sure I'm doing this wrong. Again any help is always appreciated it.

Another question I have is, how do you know if padding was applied in the first place in order to remove it? If '\07' represents 7 bytes of padding, what if the last byte was '\01\'?

+4  A: 

That is because apparently SlowAES doesn't implement the commonly used padding schemes, like PKCS: Issue 4: Implement PKCS7 padding. Even if the library doesn't implement it, it's really trivial for you do implement it: once you get the decrypted (padded) text, just analyze the last block and deduct the original length from the padding info. The PKCS7 padding is described in RFC2315 if I'm not mistaken.

Updated

If text is padded with PKCS7 the very last byte in the decrypted text will contain the length of the padding. So you decrypt and then remove as many characters from the end of the decrypted text as the value on the last byte. Eg.

  1. the original text is 'This is the original text'. It has length 25.
  2. the encryption will padd the length to 32 (next block of 16 size), so it will encrypt the block 'This is the original text\07\07\07\07\07\07\07'.
  3. the padded block gets encrypted into 32 length crypt text
  4. you decrypt the 32 length crypt and get back the padded text from 2)
  5. last byte of the decrypted block is '\07', so you substract 7 bytes from the decrypted block. The result is the original text, of length 25: 'This is the original text'

PS: I would add the JavaScript code, but my JavaScript coding skill is rather rusty.

Remus Rusanu
RFC2315 section 10.3, note #2 for the padding.
GregS
Thanks for the quick response Remus and Greg. The problem is some of this is definitely over my head. I don't know how to analyze the last block. Any tips or help on how to figure this out would be great. And thanks again!
Rick
A: 

One thing you can do is pad your data to round out to a complete 128-bit block size. that way you don't have to worry about PKCS#7 padding, because you just did it yourself. hardly optimal, but at least you're up and running :)

Michael Howard-MSFT
Thanks Michael for the input. I'm not sure how to always make sure my original, unencrypted text, always rounds out to be a complete 128-bit block.Like I said I'm new to this cryptology stuff and a lot of it is over my head.Thanks again for your advice.
Rick