Java vs C++ AES Encryption gives different values. Padding issue?

[B@33bfc93a is encrypted (java)

szDataOut is
áÄóhçî¬ê¢h½qá!ëæQtA,dÐÒt÷("R

Completely different it seems until its base64? Not sure.. I'm not sure what exactly I should do here though..

Is there a better way to match up using AES as well if this is incorrect then?

No, no -that's not the way to do it ;-) Do it as below and the same with printf in the C++ app

        for(int i = 0;i < encrypted.length;i++) {
            System.out.printf("%02x\n", encrypted[i] & 0xff);
        }

                                              

1:
2:
3:

far easier to compare the base64 :)

C++:
e1
c4
f3
68
7f
e7
ee
80
ea
a2
68
bd
71
e1
21
eb
e6
51
74
8d
41
2c
61
04
d0
d2
74
16
f7
28
22
8c
06


JAVA:
e1
c4
f3
68
7f
e7
ee
80
ea
a2
68
bd
71
e1
21
eb

That is both of them, what is wierd is it seems to start off the same, then ends differently. Not sure why this could be yet either.

java code looks fine, though u shouldn't rely on the default character encoding and instead explicitly specify the encoding when converting between strings and byte arrays.

good test would be to try and decrypt the encrypted string as see i you get the same back

>>java code looks fine, though u shouldn't rely on the default character encoding and instead explicitly specify the encoding when converting between strings and byte arrays.
Accept Multiple Solutions

What do you mean exactly? Like using UTF?


>>good test would be to try and decrypt the encrypted string as see i you get the same back

I will try this soon, I do know if I decrypt it in java or C++ using the same encryption it works fine, haven't tested it through lets say, getting it in java and decrypting in C++ yet though.

Well the status update is.

I can convert from encrypt in C++ and decrypt in Java, and it seems fine.

However, If I encrypt in Java and decrypt in C++, I get the value

"aaaaaaaaaaaaaaaa6¤Ü´D<àdNÉ
ñÊ      "

But the actual value is only 'aaaaaaaaaaaaaaaa'

Which is wierd.. Because Java is 'smaller', when encrypted it is: 4cTzaH/n7oDqomi9ceEh6w==

But in C++ the encrypted is:  4cTzaH/n7oDqomi9ceEh6+ZRdI3Hc04K0NJ0FvcoIow=


Those are the base64 results (just to state again).

However if I just do C++ encrypt and decrypt is works fine, same with java.

That output is curious. Can you show the C++ code you used to produce it?

btw, i mean your earlier output. Your latest wasn't there when i posted. Unless you've done something odd to produce the C++ output, your problem is nothing to do with base64 or character encoding btw

check your string termination in C++

Oh the encryption part of C++? It is:

      //One block testing
      CRijndael oRijndael;
      oRijndael.MakeKey("abcdefghabcdefgh", CRijndael::sm_chain0, 16, 16);
      char szDataIn_Orig[] = "aaaaaaaaaaaaaaaa";

        //Test ECB
      int nLen = strlen(szDataIn_Orig);
      int nBlockLen = ((int)nLen / 16 + 1) * 16;
      char *szDataIn = new char[nBlockLen + 1];
      memset((char *)szDataIn, 0, nBlockLen + 1);
      strcpy(szDataIn, szDataIn_Orig);

      // To encrypt
      char szDataOut[17] ="\0";

      oRijndael.Encrypt(szDataIn, szDataOut, nBlockLen, CRijndael::ECB);

      std::string encoded = base64_encode(reinterpret_cast<const unsigned char*>(szDataOut), nBlockLen);
      
then you can do the       for(int i = 0;i < len(szDataOut);i++) { printf and get the data. which resulted in:

e1
c4
f3
68
7f
e7
ee
80
ea
a2
68
bd
71
e1
21
eb
e6
51
74
8d
41
2c
61
04
d0
d2
74
16
f7
28
22
8c
06

szDataOut looks too long, try filling it with \0 initially

>>then you can do the

No- you should be printing the value of szDataOut as soon as encryption's been performed. Also, you seem to be hardcoding the length of that buffer to 16 - why?

>>No- you should be printing the value of szDataOut as soon as encryption's been performed

Oh sorry, yes that what I was doing though, my bad on telling it like that!

About the hard coding, was just a quick test, I though it would be okay but I suppose I see now it's not. Do youmean the library (the encryption library) should give some length result for me to use?

the hard coding is fine, but I'd suggest filling it with \0

Well it definatly has to be something then, With java just after encryption (No b64 yet)

e1
c4
f3
68
7f
e7
ee
80
ea
a2
68
bd
71
e1
21
eb

and C++, using the encrypted/base64ed java string, decrypted BASE64 is:
e1
c4
f3
68
7f
e7
ee
80
ea
a2
68
bd
71
e1
21
eb

Seems similar, so that rules out base64 doing it ;) I will give the nBlockLen and check!

That seemed to work, Output in C++ is now

4cTzaH/n7oDqomi9ceEh6w==

which is exact to the Java. I removed nblocklen, and just used nLen

      int nLen = strlen(szDataIn_Orig);
      char *szDataIn = new char[nLen + 1];
      memset((char *)szDataIn, 0, nLen + 1);
      strcpy(szDataIn, szDataIn_Orig);

      // To encrypt
      char szDataOut[17] ="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0";


However, if I don't wish for it to be hard coded, would I do something similar to szDataOut and then set it with \0's? Java doesn't seem to be needed to be hardcoded so would be good to be similar.

Alright, good to know :) I will mark this as done for now as what I wanted (Exact duplicates) is what I wanted! Understanding a bit more now is good. On to using CBC and such for tests now :P

Posted another, http://www.experts-exchange.com/Security/Encryption/Q_24645910.html .. IV stuff. Apologies for so many questions, I'm very new to java, and especially encrypting!