1. 密文检索概述
密文检索，说白了就是在数据加密的状态下，还能对密文进行搜索。你想想看，用户把敏感数据交到云上，又不希望服务商看到明文，这时候加密是必须的。但加密之后传统索引、关键词搜索全废了，咋办？密文检索就是来解决这个矛盾的。
我在这行干了快十年，刚接触密文检索时也被绕晕过。后来亲手搭过几套审计日志系统，踩过不少坑，才慢慢摸清里面的门道。今天咱们先把基础打牢，后面章节再聊性能调优和巡检实战。
1.1 核心问题
传统检索依赖明文的倒排索引、B-tree、全文分词这些技术。一旦加密，数据变成无规律的二进制串，这些技术全失效。密文检索要同时满足三个条件：
- 机密性：服务器不知道明文内容，也不知道搜索关键词。
- 可检索性：用户能用加密后的凭证在密文上执行搜索，得到正确结果。
- 效率：不能比明文检索慢太多（嗯，这是一个“既要又要”的问题）。
1.2 加密算法选型
我建议先从算法分类入手。下表列出了密文检索中常用的几类加密方案：
| 算法类型 | 典型代表 | 特点 | 适用场景 |
|---|---|---|---|
| 对称加密 | AES、SM4 | 速度快，密钥管理简单 | 存储层数据加密 |
| 确定性加密 | AES-SIV、OPRF | 相同明文加密结果相同，可实现等值检索 | 精确关键词匹配 |
| 可搜索加密（SSE） | Boneh-Waters、Cash等人方案 | 支持密文上的关键词检索，分静态和动态 | 审计日志、邮件检索 |
| 同态加密（部分） | Paillier、CKKS | 可对密文做简单运算，但性能开销极大 | 统计查询、安全计算 |
我个人习惯在审计日志场景中选择确定性加密 + SSE 的组合。确定性加密用于对日志中的搜索关键词（比如用户ID、时间戳）做加密，保证每次加密结果一致，这样就能建索引。SSE 则负责管理索引和搜索令牌，防止服务器通过模式匹配推断用户行为。
但要注意：确定性加密有个“模式泄露”问题（相同明文出现次数会被统计），我经历过一次事故：攻击者通过频率分析推断出了密文对应的敏感操作类型。后来我们在上层加了填充机制才堵住这个漏洞。后面章节我会详细讲。
1.3 安全模型
密文检索的安全模型，常见的就两大类。我画了一张图帮大家理解：
安全模型对比速览
- 语义安全（IND-CPA）：攻击者无法区分两个相同长度的明文。但不一定能隐藏搜索结果模式。
- 自适应不可区分安全：攻击者可以动态发起查询，依然无法获得除已泄露信息外的其他数据。这是“Goldilocks”级的安全——够用且可行。
1.4 避坑指南
我曾经在项目中犯过的错： 以为用 AES-CTR 把所有字段加密就行，结果发现搜索时只能全量解密。后来换成确定性加密 + SSE 动态索引，检索性能提升了三个数量级。
小提示：如果你只需要精确关键词搜索（比如查某个用户ID的所有审计日志），确定性加密就够。如果需要模糊匹配、范围查询，那就得上更复杂的 SSE 或部分同态方案。别一开始就上“高大上”的算法，性能往往吃不消。
1.5 本章小结
密文检索不是单点技术，而是加密算法、索引结构、安全模型的组合。我个人的经验是：先明确业务需求（搜什么？多大规模？允许泄露哪些信息？），再选加密方案。通常我会按这个步骤走：
- 确定搜索维度（关键词、范围、通配符？）
- 选择加密模式（确定性加密打底，SSE 兜底）
- 评估安全模型（自适应安全是业界标准，别偷懒）
- 压测性能（密文检索的开销主要在令牌生成和索引匹配）
后面章节我们会把审计日志的具体方案、巡检脚本优化、性能参数调校一条龙讲完。先消化一下上面的基础，有问题随时在群里讨论。