一、密文检索概述

谈起密文检索，我得先跟你讲个故事。我刚工作时，参与过一个医疗数据共享项目。数据存在云端，但医院要求：数据必须加密存储，还得支持医生按关键词搜索病历。传统的做法是啥？要么拿数据下来解密再查，要么直接明文索引。前者效率低得让人抓狂，后者安全上又埋了个大雷。

这正是密文检索要解决的问题——数据全程加密，但检索功能不丢。说白了，就是让服务器在一堆密文里，精准找出你要的那条，而它自己都不知道搜的是什么内容。

1.1 什么是密文检索

用一个场景来理解：

你有一个加密的数据库，里面存着客户的合同。现在你想查所有含“特斯拉”关键字的合同。普通的检索，得把数据库解密成明文，然后跑 LIKE 查询。云服务商这时候就能看到你的商业机密了。

密文检索的做法不同：

• 数据入库前，先加密，同时在密文上构建一个可检索的索引结构。
• 查询时，把关键词也做加密处理，生成一个“查询令牌”。
• 服务器拿着令牌去搜索引，找到匹配的结果。

整个过程，服务器看到的全是密文和令牌，没法知道明文内容。我自己在项目中遇到过好几回，客户最关心的就是这个点：“凭什么我存在你云上的数据，你还能让我精准检索？”——凭的就是这套加密和索引的技术。

1.2 基本原理

它的核心框架，我习惯用三个模块来拆解：

1. 加密模块：用密钥把原始数据转换成密文。
2. 索引模块：从明文中提取关键词，构建一个既能保护隐私、又能高效检索的结构。
3. 查询模块：用同样的密钥，把查询词转成可匹配的令牌，去索引里做比对。

你想想看，这不就是“用密码学给数据库加了一层搜索加速器”吗？

1.3 常见加密方案

1.3.1 对称加密

对称加密是基础中的基础。加密和解密用同一把密钥。最常见的是 AES，速度快，适合海量数据。

但在密文检索场景里，直接用对称加密会有个问题：无法直接对密文做比较或匹配。比如 AES 加密同一段文本两次，每次得到的密文都不同（因为有 IV 参与）。那你拿什么去索引？

所以单纯用对称加密，做不了密文检索。它更多是用来加密“数据本体”的。

1.3.2 可搜索加密

这才是密文检索的核心技术。可搜索加密（Searchable Encryption, SE）允许在密文上做关键词搜索。

主流分两类：

类型	原理	典型方案	适用场景
对称可搜索加密（SSE）	双方共享密钥，构建加密的倒排索引	Song-Wagner-Perrig 方案、Curtmola 方案	单用户、小规模系统，性能最好
公钥可搜索加密（PEKS）	用接收方公钥加密关键词，生成搜索令牌	Boneh et al. 方案	多发送方场景，比如邮件过滤、IoT采集

我自己在实际的接口测试中，踩过一个坑：选择方案时只看了安全性，没管性能。结果索引构建慢得像蜗牛，几万条数据就得跑几分钟。做自动化测试时，超时配置都改了好几轮。

再讲一个细节：密文检索的安全级别。学术界一般分为几个层次：

• CKA1：只隐藏关键词本身，不隐藏搜索模式。
• CKA2：更强的安全性，能抵抗选择关键词攻击。
• IND-CKA：抗自适应敌手，安全性更高。

我做自动化测试时，会把每个安全级别的差异做成一个配置参数。为什么这么弄？因为在不同客户现场，安全等级要求不同。接口测试用例得跟着变——这才是自动化测试的灵活之处。

1.4 知识体系总览

下面这张图，能帮你快速建立起密文检索的知识骨架。我画的是密文检索的信息流架构：