[openssl-users] openssl des-ede3-cbc does not match with Java one

[Viktor Dukhovni]

On Wed, Nov 25, 2015 at 09:18:15AM +0100, David García wrote:

> H6cr2yN8oWV6AUY/JlknQw==

Decrypting in ECB mode you get:

    $ echo H6cr2yN8oWV6AUY/JlknQw== |
	openssl base64 -d |
	openssl enc -d -des-ede3 -K 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -nopad |
	hexdump -ve '/1 "%02x"'; echo
    30303538363333332fa02cdc247ba662

> but is not exactly the same result I get for the same input in my Java and
> PHP examples. In those ones I get:
> 
> H6cr2yN8oWUVY3a6/Vaaow==

Decrypting in ECB mode you get:

    $ echo H6cr2yN8oWUVY3a6/Vaaow== |
	openssl base64 -d |
	openssl enc -d -des-ede3 -K 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -nopad |
	hexdump -ve '/1 "%02x"'; echo
    30303538363333332fa72bdb237ca165

The initial 8-byte blocks are identical, but the trailing blocks
differ subtly.  The hexdump of the OpenSSL ciphertext is:

    $ echo H6cr2yN8oWV6AUY/JlknQw== |
	openssl base64 -d |
	hexdump -ve '/1 "%02x"'; echo
    1fa72bdb237ca1657a01463f26592743

If you XOR the common first block of ciphertext into each of the
second decrypted blocks you get:

    $ perl -le '
	for ( (0x2fa02cdc247ba662, 0x2fa72bdb237ca165) ) {
	    printf "%016x\n", ($_ ^ 0x1fa72bdb237ca165)
	}'
    3007070707070707
    3000000000000000

What you see is the effect of PKCS#5 padding in the case of OpenSSL,
and zero-padding (which is not reversible and not suitable for
encrypting ciphertext that is a not a multiple of 8 bytes in length)
in Java.  You've failed to configure the correct padding mode.

-- 
	Viktor.