DBMS_CRYPTO不能直接ALTER COLUMN加密，必须封装函数或触发器；生产落地需先确保权限、显式字符集转换（AL32UTF8）、明文/密钥/IV均转RAW；仅推荐AES_CBC_PKCS5组合；密文须BASE64编码后存VARCHAR2；IV必须每次随机生成且持久化。

DBMS_CRYPTO

可以直接在数据库层对敏感列加密，但**不能直接 ALTER COLUMN 加密**——它不改变列类型或自动加解密，必须靠应用逻辑或触发器/函数封装。真正在生产环境安全落地，关键不在“能不能”，而在“怎么避免裸密钥、乱码、跨系统不一致”。

加密前必须做三件事：权限、字符集、RAW 转换

没这三步，后面全白搭。

• 确认用户有 EXECUTE ON SYS.DBMS_CRYPTO 权限，否则调用 ENCRYPT 直接报 ORA-00904 或 ORA-01031
• 明文必须转成 RAW，且字符集要显式指定：UTL_I18N.STRING_TO_RAW('张三', 'AL32UTF8')；用 UTL_RAW.CAST_TO_RAW 会丢 Unicode 字符（比如中文变问号）
• 密钥和 IV 也必须是 RAW，不能传字符串字面量：'mykey123' 是错的，得用 UTL_I18N.STRING_TO_RAW('mykey123', 'AL32UTF8')

ENCRYPT 的 cipher_type 参数别硬凑，只用已验证组合

Oracle 实际支持的 AES 模式很有限，DBMS_CRYPTO.AES_CBC_PKCS5 是唯一推荐的稳定组合（等价于 ENCRYPT_AES + CHAIN_CBC + PAD_PKCS5）。其他常见错误包括：

• 误用 DBMS_CRYPTO.AES_ENCRYPT —— 这不是合法常量，编译就报 PLS-00302
• 选 CHAIN_ECB —— ECB 模式禁用，相同明文块永远生成相同密文块，完全不满足脱敏合规要求
• 填 PAD_NONE 或 PAD_ZERO —— Oracle 对非 PKCS5 填充支持极差，Java/.NET 解密时大概率报 BadPaddingException

密文不能直接存 VARCHAR2，必须 BASE64 编码

ENCRYPT 返回的是二进制 RAW，若直接插入 VARCHAR2 字段，Oracle 会隐式调用 UTL_RAW.CAST_TO_VARCHAR2，导致截断、乱码或 ORA-28834: buffer too small。

Crypto Whale Intelligence

用于加密鲸情报的自动化技能

下载

• 加密后立刻用 UTL_ENCODE.BASE64_ENCODE 转成可存储字符串：UTL_I18N.RAW_TO_CHAR(UTL_ENCODE.BASE64_ENCODE(encrypted_raw), 'AL32UTF8')
• 解密前反向操作：先 UTL_I18N.STRING_TO_RAW 转回 RAW，再 UTL_ENCODE.BASE64_DECODE 还原为原始密文 RAW
• 别用 RAWTOHEX —— 输出长度翻倍（2 字节 → 4 字符），占空间且难读；BASE64 长度只增约 33%

IV 必须随机生成、随密文持久化，不能复用或硬编码

IV 不是密钥，但重复使用同一 IV + 同一密钥，会让攻击者通过密文比对还原明文结构（尤其短字段如手机号、身份证号）。

• 每次加密都调用 DBMS_CRYPTO.RANDOMBYTES(16)（AES-128/192/256 的 IV 都是 16 字节）
• IV 可明文存储，建议和密文拼接（如 iv || encrypted_raw），或单独建 RAW(16) 列保存
• 解密时必须把原 IV 原样传入 DECRYPT 的 iv 参数；漏传或传错会报 ORA-28233: invalid input to encrypt/decrypt
• 严禁用 SYS_GUID() 或 DBMS_RANDOM —— 它们不是密码学安全随机源，RANDOMBYTES 才是唯一合规选择

真正难的不是写通一个加密函数，而是让密钥管理、IV 生命周期、跨语言兼容、错误诊断全部闭环。比如密钥轮换时，旧密文怎么批量重加密？IV 存储格式变更会不会导致历史数据不可读？这些细节一旦漏掉，上线后就是线上事故。