Reputation: 13
I got an annoying issue I'm out of ideas with. When using the DBMS_CRYPTO.ENCRYPT function of the oracle dbms_crypto package I get a different result in oracle 11C and oracle 19. I first noticed this issue when migrating a database from 11c to 19c and running into issue decrypting stored values.
The following sql query illustrates this issue:
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;
In oracle 11c this query returns 9A18D619A269A5AF9716F2869A8A4F5F
while in oracle 19c it returns 049AFACC8EC7AE239EC496E5B4534048
.
I have been trying to figure out what could cause this difference. I checked the sub-parts of the query and I isolated the first difference to the output of the encrypt function.
I also checked with different databases of 11g and the query always gave the same result.
Did someone else encounter this issue before and knows how to solve this? Or can someone give me some pointers as to what would influence the functions from the query?
Upvotes: 1
Views: 1489
Reputation: 8361
@TenG's hint was spot on.
typ = 5128 = 0x1408
0x1000 PAD_PKCS5
0x0400 CHAIN_OFB
0x0008 ENCRYPT_AES256
11.2 9A18D619A269A5AF9716F2869A8A4F5F
12.1 049AFACC8EC7AE239EC496E5B4534048
According to Oracle Support Doc ID 2014909.1, OFB mode was not properly implemented in 11.2 and was in fact doing the ECB chaining.
0x1000 PAD_PKCS5
0x0300 CHAIN_ECB
0x0008 ENCRYPT_AES256
typ = 4872 = 0x1308
11.2 9A18D619A269A5AF9716F2869A8A4F5F
12.1 9A18D619A269A5AF9716F2869A8A4F5F
In other words, in 11.2, if you asked for OFB, you got ECB instead. If you ask for ECB, you get the same value in both versions.
Upvotes: 1