RDBMS：使用语义安全加密时如何保留唯一/主键列的重复检测？

你遇到的这个问题确实很常见——语义安全加密（比如带随机IV的AES-CBC）能让同一明文生成不同密文，有效防止攻击者通过密文重复推断明文，但代价就是破坏了依赖密文唯一性的数据库约束（UNIQUE索引、PRIMARY KEY）和INSERT ON DUPLICATE KEY UPDATE这类重复抑制逻辑。下面分享几个行业内成熟的解决方案，以及对你提出的KDF思路的分析：

1. 确定性加密（简单但需谨慎使用） #

如果对数据敏感度要求不高，或者可以接受一定的安全trade-off，确定性加密是最直接的选择。比如AES-ECB模式（MariaDB内置AES函数默认用这个）、或者带固定IV的AES-CBC，都会让同一明文生成完全相同的密文，天然支持重复检测。

但要注意：这种方式不具备语义安全性——攻击者只要看到重复的密文，就能推断出对应的明文是相同的，比如能识别出哪些用户的姓名一致。如果你的数据涉及隐私合规（比如GDPR、HIPAA），这种方案大概率不符合要求。

2. 独立盲哈希列（你的思路的优化版，推荐） #

你想到的新增KDF哈希列的方向是对的，只要做一点关键调整就能避免破坏语义安全：

• 给哈希列用独立的保密盐/密钥：绝对不要和加密用的盐或密钥共享。比如加密用密钥A、随机IV，而哈希用密钥B（或独立的盐值），用PBKDF2、Argon2这类抗碰撞的KDF生成哈希值。
• 安全性分析：只要哈希的密钥/盐不泄露，攻击者无法从哈希值反推明文，也没法把哈希值和密文关联起来——因为两者的生成逻辑完全独立。这样既保留了重复检测能力（通过哈希列的UNIQUE索引），又维持了语义安全：攻击者看到相同的哈希值，只能知道对应明文相同，但不知道明文内容，也找不到对应的密文。
• 实现步骤：插入数据时，先对明文用哈希密钥生成哈希值，存入带UNIQUE索引的独立列；再对明文做语义安全加密，存入密文列。检查重复时，先计算明文的哈希值，通过哈希列查询是否存在重复，再处理加密后的插入/更新逻辑。

3. 可搜索加密（高级场景适用） #

如果对安全性要求极高，且需要更复杂的加密数据查询能力，可搜索加密（Searchable Encryption）是更专业的方案：

• 对称可搜索加密（SSE）可以生成一个“搜索令牌”，用这个令牌就能在加密数据中匹配到对应的密文，全程不需要解密数据。而且设计良好的SSE可以保持语义安全，不会泄露明文的重复信息，除非你主动生成对应令牌去查询。
• 缺点是实现复杂度高，数据库原生支持少，通常需要自己实现或者使用成熟的加密库，适合有特定高安全需求的场景。

对你的思路的补充 #

你担心的“攻击者识别相关密文”问题，只要保证哈希列的密钥/盐和加密列完全独立，就完全不会发生。哈希值和密文之间没有任何可被利用的关联，攻击者无法通过哈希值找到对应的密文，反之亦然。这种独立盲哈希的方案是目前平衡安全性和实用性的主流选择，很多隐私合规场景下都在使用。

内容的提问来源于stack exchange，提问作者Branko B