密文检索模型：倒排索引、布隆过滤器与 ORAM
讲这一节前，我先说个背景。做密文检索，说白了就是：你不信任数据库服务商，但你还要能搜自己的数据。数据加密存进去，怎么搜？我当时接审计日志项目时，差点就以为把关键词加密后直接 LIKE 就能搞定……后来一想，密文 LIKE 根本不 work。
好了，咱们一个个看。三种主流模型：倒排索引、布隆过滤器、Oblivious RAM（ORAM）。先理解，再对比选型。
1. 倒排索引结构：从明文到密文的改造
倒排索引，搞搜索引擎的都熟。每个关键词对应一个文档 ID 列表。密文场景下，关键词本身要加密，文档 ID 也要加密。你想想看，加密后还能搜索吗？
常见的做法：把关键词拆成 n-gram 或直接加密，然后通过可搜索加密（SSE）的“”映射。我遇到过一个人，他把整个倒排列表存进加密数据库，搜索时先生成 ，再用 去匹配。行得通，但性能开销取决于倒排列表的大小。
- 关键词加密：用伪随机函数（PRF）生成“标签”，搜索时用同样的 PRF 算出标签去匹配。
- 文档 ID 加密：可以用对称加密，但检索时需要先拿到整个列表才能解密。我习惯用“加密的布隆过滤器”来加速——哎呀，提前到后面讲了。
- 存储膨胀：每个关键词要额外存索引表，可能膨胀 1.5~2 倍，还能接受。
2. 布隆过滤器：空间高效的存在性判断
布隆过滤器，一个位数组加一堆哈希函数，能告诉你“这个元素肯定不在集合里”，但说“在”时可能误判。密文场景怎么用？
最简单的：把关键词的哈希值映射到位数组中。但这样一来，位数组本身是明文，攻击者能通过位数组的模式推断关键词分布。所以需要加密位数组，或者用“加密的布隆过滤器”——实际上可以用 PRF 替代普通哈希，然后服务器持有一个加密状态。
我曾经踩过一个坑：假阳性率设得太低，导致过滤器太大，密文检索反而比直接查索引还慢。后来我调参数：每元素 8~12 位，4~6 个哈希函数，假阳性率控制在 0.1% 左右。
3. Oblivious RAM (ORAM)：访问模式隐藏的终极方案
ORAM 不是用来加速的，是用来“隐藏”的。它不光加密数据内容，还隐藏你访问了哪些位置。想想看，就算倒排索引加密了，服务器还是能看到你每次查询访问了哪些块——这些访问模式能泄露大量信息。ORAM 就是解决这个问题的。
但代价巨大。经典的 Tree ORAM 每次访问要读取 O(log N) 个块，还要重洗整个数据库。我测试过 Path ORAM，对于百万级数据，单次查询要 100~200ms，无法用于在线检索。
- 安全等级最高：强安全模型下，ORAM 是目前唯一能抵抗访问模式泄露的方案。
- 性能瓶颈：存储开销 N*C（C 约 2~4），实际落地困难。更适合离线安全审计。
- 结合使用：可以用 ORAM 保护元数据，用倒排索引保护高频搜索内容。我在项目里试过，只能作为最后防线。
4. 多种方案对比
我直接用一个表格总结，看着清楚。
| 维度 | 倒排索引（SSE） | 布隆过滤器 | Oblivious RAM |
|---|---|---|---|
| 加密开销 | 低（仅对关键词和 ID 加密） | 中（位数组加密 / 伪随机哈希） | 高（每访问重洗整个桶） |
| 查询复杂度 | O(倒排列表长度) | O(k) k为哈希次数 | O(log N * L) L为块大小 |
| 存储膨胀 | 1.5x ~ 3x | 0.1x ~ 0.5x（取决于假阳性率） | 2x ~ 4x |
| 安全等级 | 中（泄露访问模式） | 中低（位数组可能泄露统计） | 高（隐藏所有访问模式） |
| 适用场景 | 高频关键词搜索 | 存在性判断 / 过滤 | 隐私强制环境 / 安全审计 |
下面这张图，把三种模型的核心流程画在了一起，方便对照。
三种方案，没有银弹。倒排索引适合高频、实时场景；布隆过滤器适合快速过滤、去重；ORAM 只在隐私要求极高时才上。我一般按这个逻辑选：先判断是否允许泄露访问模式？如果允许，倒排就够了；如果不允许，再考虑是否接受高延迟——能接受就上 ORAM，不能接受则用布隆过滤器加一些 padding 技术。