MySql和Oracle加密函数兼容性

Posted 2021-04-30 浩浩点滴

  公司有个收单项目，为了央行合规检查，一些敏感字段需要加密存储（如卡号等），该系统是基于Oracle，加密密方法是基于Oracle的DBMS_CRYPTO包来实现Function，应用通过调用Function来实现加密和解密的；现在该系统的数据库要从Oracle迁移到mysql，为了避免数据迁移，最好在MySql也实现同样功能的加密Function，Mysql也有AES_DECRYPT和AES_ENCRYPTh函数，做了一下实验对比，发现同样的原文MySql加密结果和Oracle加密结果不一样。

MySql加密方法：

select HEX(AES_ENCRYPT('hello world', 'key'));

Oracle加密方法：select DBMS_CRYPTO.ENCRYPT(UTL_I18N.STRING_TO_RAW(‘hello world‘),DBMS_CRYPTO.ENCRYPT_AES128 + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5,UTL_I18N.STRING_TO_RAW(’key‘)) from dual;

MySql的AES_ENCRYPT没有设置AES具体分块方法和Padding方法，后来查资料可以通过以下方法设置：

SET block_encryption_mode = 'aes-128-cbc';

默认通过是‘aes-128-ecb'

通过SELECT @@session.block_encryption_mode; 语句可以查看

设置好在再执行下述的SQL

select HEX(AES_ENCRYPT('hello world', 'key', '0000000000000000'));

其中'0000000000000000' 为CBC分块所需要的向量；查看Oracle DBMS_CRYPTO.ENCRYPT的API，默认为NULL，就是说可以不设置，那应该是多少呢？

在DBMS_CRYPTO.DECRYPT API中有说明，默认为all zero；

但上述SQL执行结果还是和Oracle的执行结果不符；

后来想起all zero，应该是二进制的16个0，而不是字符串16个0；改为这样：

select HEX(AES_ENCRYPT('hello world', 'key', UNHEX('00000000000000000000000000000000')));

执行结果和Oracle执行相符。OK，完工，花费了一下午时间。

注：由于原来的加密会涉及敏感数据（主要是密钥），所以文中例子数据都是非实际例子。