密文检索技术概述
这一章我们聊聊密文检索。说白了，就是数据加密之后，还得能搜。你想想看，数据都加密了，服务器看到的是一堆乱码，怎么知道哪条记录包含某个关键词？传统思路是把数据解密了再搜——那加密还有什么意义？密文检索，就是带着镣铐跳舞，在不解密的前提下完成搜索。
2.1 核心思想
密文检索的核心，其实就三步：
- 构建索引 —— 对明文内容提取关键词，生成可搜索的加密索引。
- 生成陷门 —— 用户想要搜索某个词时，用密钥生成一个“令牌”（陷门），发给服务器。
- 匹配检索 —— 服务器拿着陷门，在加密索引里做比对，返回命中的文件指针。
整个过程，服务器始终看不到关键词的明文，也看不到文件的原文。我记得在做一个内部审计日志系统时，甲方要求日志必须全程加密，但又需要按用户ID和时间范围精准查询。如果每次查询都全量解密，性能肯定崩。最后我们用了基于倒排索引的对称可搜索加密方案，才能在加密状态下做到毫秒级响应。
关键约束：密文检索必须在不泄露关键词和不暴露文档内容的前提下，返回正确的结果集。泄露哪怕一点点统计特征，都可能被攻击者利用。
2.2 发展历程
密文检索不是横空出世的。它的演变脉络很清晰：
| 阶段 | 时间 | 里程碑 | 我的一点看法 |
|---|---|---|---|
| 理论起步 | 2000年 | Song等人首次提出对称可搜索加密（SSE）概念 | 那时还是纯学术，没人想得到能落地 |
| 公钥扩展 | 2004年 | Boneh等人提出公钥可搜索加密（PEKS） | 解决多方场景下的搜索问题，但效率是硬伤 |
| 效率优化 | 2010-2015 | 动态SSE、支持布尔查询、倒排索引方案出现 | 我在项目中用的就是这一代技术，性能终于能看了 |
| 工业落地 | 2016-2020 | AWS、Google等云厂商推出加密检索服务 | 但大多还是私有方案，开源选型很有限 |
| 隐私增强 | 2020至今 | 支持可验证性、隐藏访问模式、抗泄露 | 面对侧信道攻击，我们还在赛跑 |
为什么会这样发展？早期学术界关注的是“能不能做”，后来业界关注的是“能不能快、能不能安全”。我建议你重点看2010年之后的技术，那是真正能落地的起点。
2.3 主要分类
密文检索按密码学基础分为两大阵营：对称可搜索加密（SSE）和公钥可搜索加密（PEKS）。嗯，这里要注意，两者不是替代关系，而是适用场景不同。
2.3.1 对称可搜索加密（SSE）
SSE用的就是对称密钥。数据拥有者和搜索者是同一个人，或者共享同一个密钥。特点很明显：
- 效率高 —— 对称加密加解密快，索引结构紧凑。我实际压测过，百万量级文档的搜索时间在20ms以内。
- 功能丰富 —— 支持布尔查询、范围查询、排序等。常见方案有基于倒排索引的DSSE、基于布隆过滤器的OXT等。
- 密钥管理简单 —— 但这也意味着共享密钥的人都能搜，权限控制粒度粗。
SSE的典型流程（伪代码示例）：
// 数据拥有者加密文档并构建索引
for each document d:
encrypt(d) → E(d)
for each keyword w in d:
store (w, docID) into inverted index
// 用户搜索关键词 w
trapdoor = PRF(K, w) // 用伪随机函数生成陷门
send trapdoor to server
server: scan encrypted index, find all matching docIDs
return encrypted documents2.3.2 公钥可搜索加密（PEKS）
PEKS用公钥加密索引，私钥生成陷门。适合多对一或一对多的场景，比如医生上传加密病历，患者（或授权方）用私钥搜索。不过代价也明显：
- 计算开销大 —— 涉及双线性对运算，搜索时间比SSE高两个数量级。我测过，百万级文档的PEKS搜索要数秒。
- 不支持复杂查询 —— 大多数PEKS方案只支持单关键词精确匹配，扩展性受限。
- 安全性更强 —— 公钥体系天然支持非交互式授权，适合跨组织的审计场景。
2.4 适用场景对比
我习惯用下面这个矩阵来做技术选型：
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 个人云盘加密检索 | SSE（静态或动态） | 你自己加密、自己搜，密钥不共享 |
| 企业审计日志查询 | SSE + 属性基加密 | 需要细粒度权限，但搜索性能优先 |
| 医疗数据跨机构检索 | PEKS 或混合方案 | 多机构公钥发布，私钥各自保管 |
| IoT设备数据检索 | 轻量级SSE（如布隆过滤器） | 设备资源受限，PEKS算不动 |
| 防泄漏（DLP）内容扫描 | SSE + 密文模式匹配 | 需要正则匹配，PEKS搞不定模糊搜索 |
你想想看，DLP合规审计日志这个场景，日志是动态写入、需要按关键词和时间段查询、权限分部门，而且性能要够快。这种场景SSE是更务实的选择。但这不代表PEKS没用，在需要非对称分发的场景里，它是唯一选项。
2.5 本章知识图谱
上面这张图我把SSE和PEKS的核心特性、适用场景都列出来了。你大概也能看出来，SSE在DLP审计日志这个场景下是更自然的选择——效率高、支持动态更新、查询灵活。但别急着下结论，后续章节我会详细拆解如何在审计日志系统中具体实现密文检索，到时候你会遇到各种坑，比如密钥轮换、索引规模膨胀、访问模式泄露……嗯，这些我们慢慢聊。