<div dir="ltr">Viktor, you pointed me to the right way. I was missing the -nopad flag in the openssl command.<div><br></div><div>I don't need to do the padding through the cipher algorithm because I do the 0 padding manually before executing the ciphering.</div><div><br></div><div>Now it matches. This is the command I am using (for this manual example I am providing an already multiple of 8 string, so I have removed the first char of the input string for testing):</div><div><br></div><div>echo -n 05863330 | openssl enc -e -des-ede3-cbc -K 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -iv 00000000 -nopad | openssl enc -base64<br></div><div><br></div><div><br></div><div>Thanks Viktor.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-11-25 10:39 GMT+01:00 Viktor Dukhovni <span dir="ltr"><<a href="mailto:openssl-users@dukhovni.org" target="_blank">openssl-users@dukhovni.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Nov 25, 2015 at 09:18:15AM +0100, David García wrote:<br>
<br>
> H6cr2yN8oWV6AUY/JlknQw==<br>
<br>
Decrypting in ECB mode you get:<br>
<br>
    $ echo H6cr2yN8oWV6AUY/JlknQw== |<br>
        openssl base64 -d |<br>
        openssl enc -d -des-ede3 -K 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -nopad |<br>
        hexdump -ve '/1 "%02x"'; echo<br>
    30303538363333332fa02cdc247ba662<br>
<span class=""><br>
> but is not exactly the same result I get for the same input in my Java and<br>
> PHP examples. In those ones I get:<br>
><br>
> H6cr2yN8oWUVY3a6/Vaaow==<br>
<br>
</span>Decrypting in ECB mode you get:<br>
<br>
    $ echo H6cr2yN8oWUVY3a6/Vaaow== |<br>
        openssl base64 -d |<br>
        openssl enc -d -des-ede3 -K 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -nopad |<br>
        hexdump -ve '/1 "%02x"'; echo<br>
    30303538363333332fa72bdb237ca165<br>
<br>
The initial 8-byte blocks are identical, but the trailing blocks<br>
differ subtly.  The hexdump of the OpenSSL ciphertext is:<br>
<br>
    $ echo H6cr2yN8oWV6AUY/JlknQw== |<br>
        openssl base64 -d |<br>
        hexdump -ve '/1 "%02x"'; echo<br>
    1fa72bdb237ca1657a01463f26592743<br>
<br>
If you XOR the common first block of ciphertext into each of the<br>
second decrypted blocks you get:<br>
<br>
    $ perl -le '<br>
        for ( (0x2fa02cdc247ba662, 0x2fa72bdb237ca165) ) {<br>
            printf "%016x\n", ($_ ^ 0x1fa72bdb237ca165)<br>
        }'<br>
    3007070707070707<br>
    3000000000000000<br>
<br>
What you see is the effect of PKCS#5 padding in the case of OpenSSL,<br>
and zero-padding (which is not reversible and not suitable for<br>
encrypting ciphertext that is a not a multiple of 8 bytes in length)<br>
in Java.  You've failed to configure the correct padding mode.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
        Viktor.<br>
_______________________________________________<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">David</div>
</div>