Home/ Questions/Q 6554873
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T12:45:07+00:00

I am in need to compare data between an Oracle database and a MySQL

  • 0

I am in need to compare data between an Oracle database and a MySQL database.

In Oracle, the data is first encrypted with the AES-128 algorithm, and then hashed. Which means it is not possible to recover the data and decrypt it.

The same data is available in MySQL, and in plain text. So to compare the data, I tried encrypting and then hashing the MySQL data while following the same steps done in Oracle.

After lots of tries, I finally found out that the aes_encrypt in MySQL returns different results than the one in Oracle.

-- ORACLE:
-- First the key is hashed with md5 to make it a 128bit key:
raw_key := DBMS_CRYPTO.Hash (UTL_I18N.STRING_TO_RAW ('test_key', 'AL32UTF8'), DBMS_CRYPTO.HASH_MD5);

-- Initialize the encrypted result
encryption_type:= DBMS_CRYPTO.ENCRYPT_AES128 + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5;

-- Then the data is being encrypted with AES:
encrypted_result := DBMS_CRYPTO.ENCRYPT(UTL_I18N.STRING_TO_RAW('test-data', 'AL32UTF8'), encryption_type, raw_key);

The result for the oracle code will be: 8FCA326C25C8908446D28884394F2E22

-- MySQL
-- While doing the same with MySQL, I have tried the following:
SELECT hex(aes_encrypt('test-data', MD5('test_key'));

The result for the MySQL code will be: DC7ACAC07F04BBE0ECEC6B6934CF79FE

Am I missing something? Or are the encryption methods between different languages not the same?

UPDATE:
According to the comments below, I believe I should mention the fact that the result of DBMS_CRYPTO.Hash in Oracle is the same as the result returned by the MD5 function in MySQL.

Also using CBC or CBE in Oracle gives the same result, since the IV isn’t being passed to the function, thus the default value of the IV is used which is NULL

BOUNTY:
If someone can verify my last comment, and the fact that if using same padding on both sides, will yield same results gets the bounty:

@rossum The default padding in MySQL is PKCS7, mmm… Oh.. In Oracle
it’s using PKCS5, can’t believe I didn’t notice that. Thanks. (Btw
Oracle doesn’t have the PAD_PKCS7 option, not in 11g at least)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    MySQL’s MD5 function returns a string of 32 hexadecimal characters. It’s marked as a binary string but it isn’t the 16 byte binary data one would expect.

    So to fix it, this string must be converted back to the binary data:

    SELECT hex(aes_encrypt('test-data', unhex(MD5('test_key'))));

    The result is:

    8FCA326C25C8908446D28884394F2E22

    It’s again a string of 32 hexadecimal characters. But otherwise it’s the same result as with Oracle.

    And BTW:

    • MySQL uses PKCS7 padding.
    • PKCS5 padding and PKCS7 padding are one and the same. So the Oracle padding option is correct.
    • MySQL uses ECB block cipher mode. So you’ll have to adapt the code accordingly. (It doesn’t make any difference for the first 16 bytes.)
    • MySQL uses no initialization vector (the same as your Oracle code).
    • MySQL uses a non-standard folding a keys. So to achieve the same result in MySQL and Oracle (or .NET or Java), only use keys that are 16 byte long.
    • 0