DBMS_CRYPTO适用于应用层可控、数据需跨系统流转且禁止明文落库的场景，如导出前加密身份证号或在Oracle XE中实现列级保护；它不替代TDE（表空间级透明加密）或Redaction（动态脱敏），因密钥需手动管理、加解密逻辑须显式编码。
直接用 dbms_crypto 加密字段值是可行的，但必须手动管理密钥、加解密逻辑和存储格式，不能替代 tde 或 redaction 这类透明方案。
什么时候该用 DBMS_CRYPTO 而不是 TDE/Redaction
它适合「应用层可控、数据需跨系统流转、且不允许明文落库」的场景。比如：导出到外部系统前临时加密身份证号，或在不支持 TDE 的 Oracle Express Edition 中做列级保护。
常见错误现象包括：ORA-28234: key length too short（密钥长度不足）、ORA-28239: no encryption key specified（未传密钥参数）、ORA-06502: PL/SQL: numeric or value error（输入长度超限或编码不一致）。
- 不要用它替代 TDE 做表空间级静态加密——TDE 是自动的、透明的、密钥由 Wallet 管理；
DBMS_CRYPTO是手动的、显式的、密钥要你自己存、自己传 - 不要用它替代 Redaction 做动态脱敏——Redaction 对用户透明、策略可开关；
DBMS_CRYPTO会把密文写进表里，应用必须配套改代码才能解密 - 如果只是防止 DBA 直接查表看到明文，优先配 Redaction；如果要保证备份文件里也看不到明文，必须用 TDE；只有当你需要「加密后数据仍能被外部系统识别格式」（如加密后仍是固定长字符串），才考虑
DBMS_CRYPTO
DBMS_CRYPTO.ENCRYPT 必须传对的四个参数
调用时漏掉任意一个都会报错或结果不可逆。最常踩的坑是混淆了 src 类型和 typ 算法标识符。
Kalshi Crypto Correlation Trader
下载
利用 BTC/ETH 相关性（β=1.3），在 BTC 大幅波动时交易 ETH 价格层市场。ETH 往往滞后于 BTC 走势，形成错价窗口...
-
src：必须是RAW类型。传VARCHAR2会隐式转 RAW，但默认用数据库字符集（如 AL32UTF8），若原始数据含非 ASCII 字符，解密时可能乱码。建议显式用UTL_RAW.CAST_TO_RAW('xxx') -
typ：算法+模式+填充组合，例如DBMS_CRYPTO.DES_CBC_PKCS5。注意PAD后缀必须匹配，AES 推荐用AES_CBC_PKCS5，别写成AES_CBC（缺填充会报 ORA-28233） -
key：长度必须严格匹配算法要求。AES-128 要 128 位 = 16 字节 RAW，AES-256 要 32 字节。用UTL_RAW.CAST_TO_RAW转字符串时，中文字符占 3 字节，容易超长 -
iv（初始向量）：CBC 模式必填，且每次加密都应随机生成（用DBMS_CRYPTO.RANDOMBYTES），不能复用。否则相同明文会产生相同密文，暴露规律
加解密结果要存成什么类型
加密输出是 RAW，但直接存 RAW 列在查询、索引、导出时极不方便。实际中几乎都转成 VARCHAR2 存储，但必须用确定性编码。
- 别用
UTL_RAW.CAST_TO_VARCHAR2—— 它依赖字符集，不可移植，且可能含控制字符 - 必须用 Base64 编码：
UTL_ENCODE.BASE64_ENCODE加密后、UTL_ENCODE.BASE64_DECODE解密前。Base64 输出全是 ASCII 可见字符，兼容所有客户端和工具 - 字段长度要预留足够：Base64 编码后体积膨胀约 33%，16 字节 RAW → 至少 24 字节 VARCHAR2；32 字节 RAW → 至少 44 字节
- 如果字段要建索引或参与 WHERE 条件，加密后无法高效等值查询（除非加函数索引 + 确定性函数），更别说范围查询
密钥千万别硬编码或存在表里
密钥一旦泄露，等于没加密。Oracle 自身不提供密钥托管服务给 DBMS_CRYPTO，你得自己设计安全边界。
- 禁止在 PL/SQL 包体里写死密钥字符串，哪怕加了注释“请勿修改”也没用
- 禁止把密钥存进普通表（哪怕加了 VPD 或 Redaction），DBA 仍有权限绕过
- 较可行的做法：密钥存在操作系统文件中（仅 Oracle OS 用户可读），启动时由外部脚本注入到包变量；或用外部密码管理器（如 HashiCorp Vault）通过 REST 调用获取，但会引入额外依赖
- 如果环境允许，优先启用 TDE 并用 Wallet 管理主密钥——
DBMS_CRYPTO的密钥管理成本远高于其加密收益
真正难的不是调通那几行 ENCRYPT，而是密钥生命周期管理、加解密上下文一致性、以及业务逻辑与加密耦合后的长期维护成本。很多项目初期跑通 demo，半年后因密钥轮换失败或某处忘记解密导致数据不可用——这些都不是函数本身的问题，而是没想清楚「谁该为密钥负责」。
