1

我有一个烦人的问题，我没有想法。当使用 oracle dbms_crypto 包的 DBMS_CRYPTO.ENCRYPT 函数时，我在 oracle 11C 和 oracle 19 中得到了不同的结果。当我将数据库从 11c 迁移到 19c 并遇到解密存储值的问题时，我首先注意到了这个问题。

下面的 sql 查询说明了这个问题：

select rawtohex(DBMS_CRYPTO.ENCRYPT(src => UTL_I18N.STRING_TO_RAW ('TOENCRYPT', 'AL32UTF8'),typ => 5128 ,key => UTL_I18N.STRING_TO_RAW ('e24WwDYbk25wqe5pevJ3g3VJgyjXr6HX', 'AL32UTF8'))) from dual;

在 oracle 11c 中，此查询返回9A18D619A269A5AF9716F2869A8A4F5F，而在 oracle 19c 中，它返回049AFACC8EC7AE239EC496E5B4534048。

我一直在试图找出可能导致这种差异的原因。我检查了查询的子部分，并将第一个区别与加密函数的输出隔离开来。

我还检查了 11g 的不同数据库，查询总是给出相同的结果。

其他人之前是否遇到过这个问题并且知道如何解决这个问题？或者有人可以给我一些关于什么会影响查询功能的指示吗？

4

1 回答 1

1

@TenG 的提示是正确的。

typ = 5128 = 0x1408 
             0x1000 PAD_PKCS5
             0x0400 CHAIN_OFB
             0x0008 ENCRYPT_AES256

11.2         9A18D619A269A5AF9716F2869A8A4F5F
12.1         049AFACC8EC7AE239EC496E5B4534048

根据 Oracle Support Doc ID 2014909.1，OFB 模式在 11.2 中没有正确实现，实际上是在进行 ECB 链接。

             0x1000 PAD_PKCS5
             0x0300 CHAIN_ECB
             0x0008 ENCRYPT_AES256
typ = 4872 = 0x1308 

11.2         9A18D619A269A5AF9716F2869A8A4F5F
12.1         9A18D619A269A5AF9716F2869A8A4F5F

换句话说，在 11.2 中，如果您要求 OFB，则您得到的是 ECB。如果你要求 ECB，你会在两个版本中得到相同的值。

于 2020-05-26T23:16:42.920 回答