After struggling to get JCE working for my application, i.e. that's
struggling with my understanding of it, I can now encrypt a packet and
decrypt it with the same java application over different machines which is
great :)

However transferring the AES encrypted packets betwen the Java application
and a C++ application does not work :(

In the case of the C++ application, it decrypts most of the Java encrypted
packet but then produces garbage for the last part.

In the reverse situation the Java tool throws an exception when trying to
decrypt a C++ application encrypted packet.

The Java application is using AES and the C++ application is using AES/CBC
via the FreeBSD Rijndael library.

Firstly I cannot get an instance of the Cipher using AES/CBC, it's either
AES or AES/CBC/PKCS5Padding, which as I understand means that in the first
case I am using AES in EBC mode?

Using AES I get the results mentioned above but if i attempt to use
AES/CBC/PKCS5Padding then the C++ application cannot decrypt any of it.

So using ECB mode in the Java application to encrypt the string
1234567890123456 I get

555b5850013762dfc9f9bc176201c3e835d790ae391552ade6102cdee575264f

When I decript with the Java application I get the correct unencrypted
results back.

However when I decrypt with the C++ application using AES in CBC mode

decrypt 555b5850013762dfc9f9bc176201c3e835d790ae391552ade6102cdee575264f

gives me 1234567890123456EKH@'r�r�

NOTE: the spaces in the output are non printable binary characters.

Yet if I chop of the last 32 characters of the input data I get the original
string back

encryption decrypt 555b5850013762dfc9f9bc176201c3e8

gives me 1234567890123456

Okay first of all I know that I need to have both applications running in
the same mode to get the correct results.

I cannot change the C++ application as other dependants have been using it
for years with the same encryption so

(1) Is it possible to set JCE to AES/CBC without the padding option?

(2) What is the final part of the encrypted packet that I am trimming off in
the successful C++ decryptions and why does this cause it to work?

(3) Although I have got the Java application successfully using JCE, I am
still unclear about the AES/CBC/PKCS5Padding option.  Apparently if I use
the CBC mode I need to set a IVParameterSpec to be passed to the
Cipher.init method when decrypting.  Why is this and what exactly is the
IVParameterSpec?

TIA,
Pep.

Pep schrieb:

> (1) Is it possible to set JCE to AES/CBC without the padding option?

AES/CBC/NoPadding

> (2) What is the final part of the encrypted packet that I am trimming off in
> the successful C++ decryptions and why does this cause it to work?
> 
> (3) Although I have got the Java application successfully using JCE, I am
> still unclear about the AES/CBC/PKCS5Padding option.  Apparently if I use
> the CBC mode I need to set a IVParameterSpec to be passed to the
> Cipher.init method when decrypting.  Why is this and what exactly is the
> IVParameterSpec?

IV stands for InitializationVector. It belongs to the Cipher Block Chaining
(CBC) mode (see http://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode ). 

Jan

Jan Peter Stotz wrote:

> Pep schrieb:
> 
>> (1) Is it possible to set JCE to AES/CBC without the padding option?
> 
> AES/CBC/NoPadding
> 
>> (2) What is the final part of the encrypted packet that I am trimming off
>> in the successful C++ decryptions and why does this cause it to work?
>> 
>> (3) Although I have got the Java application successfully using JCE, I am
>> still unclear about the AES/CBC/PKCS5Padding option.  Apparently if I use
>> the CBC mode I need to set a IVParameterSpec to be passed to the
>> Cipher.init method when decrypting.  Why is this and what exactly is the
>> IVParameterSpec?
> 
> IV stands for InitializationVector. It belongs to the Cipher Block
> Chaining (CBC) mode (see
> http://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode ).
> 
> Jan

Thanks Jan, that has removed the extra long part of the encrypted string,
however now it has the effect that the C++ program output is still not
recognised at all by Java though without errors and the Java output is now
no longer recognised in the C++ program, again without any errors :(

Cheers,
Pep.

Jan Peter Stotz wrote:

> Pep schrieb:
> 
>> (1) Is it possible to set JCE to AES/CBC without the padding option?
> 
> AES/CBC/NoPadding
> 
>> (2) What is the final part of the encrypted packet that I am trimming off
>> in the successful C++ decryptions and why does this cause it to work?
>> 
>> (3) Although I have got the Java application successfully using JCE, I am
>> still unclear about the AES/CBC/PKCS5Padding option.  Apparently if I use
>> the CBC mode I need to set a IVParameterSpec to be passed to the
>> Cipher.init method when decrypting.  Why is this and what exactly is the
>> IVParameterSpec?
> 
> IV stands for InitializationVector. It belongs to the Cipher Block
> Chaining (CBC) mode (see
> http://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode ).
> 
> Jan

The results I am getting are not what I expect.  Given the C++ program as a
reference, which is using AES/CBC, when I encrypt the string
1234567890123456 I get

555b5850013762dfc9f9bc176201c3e8

Here's what I get when I encrypt the same string in Java using the various
different Cipher settings for AES

Cipher cipher = Cipher.getInstance("AES");
555b5850013762dfc9f9bc176201c3e835d790ae391552ade6102cdee575264f

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
4e2efadaae3fe9bebb7853fb4b9b8791804022b06cbae1a36ce1f666f2ec1ea6

Cipher cipher = Cipher.getInstance("AES/CBC/NoPadding");
4e2efadaae3fe9bebb7853fb4b9b8791

Which leaves me in the strange situation that the C++ program can partially
unencrypt the Java output when using Cipher.getInstance("AES") but cannot
unencrypt anything encrypted under the other 2 modes and the Java program
cannot unencrypt anything encrypted fromthe C++ program regardless of what
I set the Java Cipher to :(

In fact it is only when I set the Java cipher to simply "AES", which is
"AES/EBC", that the C++ program comes anywhere near to understanding the
encrypted string, which can be seen by examining the leading 16 hex bytes
of the encrypted C++ and Java encrypted strings?

Cheers,
Pep.

Jan Peter Stotz wrote:

> Pep schrieb:
> 
>> (1) Is it possible to set JCE to AES/CBC without the padding option?
> 
> AES/CBC/NoPadding
> 
>> (2) What is the final part of the encrypted packet that I am trimming off
>> in the successful C++ decryptions and why does this cause it to work?
>> 
>> (3) Although I have got the Java application successfully using JCE, I am
>> still unclear about the AES/CBC/PKCS5Padding option.  Apparently if I use
>> the CBC mode I need to set a IVParameterSpec to be passed to the
>> Cipher.init method when decrypting.  Why is this and what exactly is the
>> IVParameterSpec?
> 
> IV stands for InitializationVector. It belongs to the Cipher Block
> Chaining (CBC) mode (see
> http://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode ).
> 
> Jan

Hey Jan,
        thanks again for passing me the information for the AES/CBC/NoPadding.

I have now fully resolved the problem.  It turned out that the code that
implements the C++ encryption using AES does not support a IV, instead
setting it to a IV of zeroes :(

Having found this out by ripping the old C++ code apart I can now get both
the C++ and Java applications to encrypt/decrypteach others data :)

I now intend to modify the C++ library to ensure that it does pass a IV on
to AES.

Thanks again,
Pep.