如何在采用AES 256 GCM加密的数据库中实现数据过滤查询

你当前采用的AES-256-GCM加密方案下，没有办法直接编写SQL实现加密字段的前缀匹配查询。
原因很简单：AES-256-GCM是具备语义安全特性的加密算法，哪怕是完全相同的明文，每次加密时因为随机IV的存在，最终生成的密文都是完全不同的，数据库侧完全无法从密文反推任何明文的特征，自然不可能做前缀匹配。

你可以根据业务场景选以下几种可行的改造方案：

• 方案一：新增盲索引字段（最常用，性价比最高）
  在应用层加密明文的同时，额外生成查询用的加盐哈希索引，存储在单独的数据库字段中。针对前缀匹配需求，你可以提前对明文的每一级前缀做加盐哈希，比如对于Patrick，你可以依次生成P、Pa、Pat……直到完整明文的加盐哈希，将这些哈希值存储在firstname_prefix_idx字段或者单独的索引表中。
  查询时，先在应用层将待查询的前缀Pat用相同的盐和哈希算法生成对应的哈希值，再到数据库做精确匹配即可，对应的SQL示例：

  SELECT id, email, firstname FROM users WHERE firstname_prefix_idx = '应用层生成的Pat对应的哈希值';
  

  注意哈希用的盐需要和加密密钥分开存储，不要放在数据库侧，避免拖库后被攻击者反向爆破明文。
• 方案二：切换为保留格式加密算法
  如果业务对安全等级要求没有那么高，可以将AES-256-GCM替换为保留格式加密（FPE）算法，这类算法可以让相同明文生成相同密文，甚至可以保留明文的前缀特征，让数据库侧可以直接做模糊查询，但这个方案会牺牲加密的语义安全性，敏感数据泄露风险会显著升高。
• 方案三：使用支持密态计算的数据库
  现在不少商业数据库、开源数据库插件已经支持同态加密、安全多方计算等特性，可以直接在密文状态下执行查询运算，不需要解密就能得到结果，不过这类方案改造成本和查询性能损耗都比较高，更适合体量较大的业务场景。
• 如果你当前业务数据量不大，在数据量增长到百万级别之前，现有全量拉取到应用层过滤的方案性能不会出现明显瓶颈，完全可以暂时维持现有方案，等数据规模上来之后再做改造。

内容的提问来源于stack exchange，提问作者Jakub Bednár