📚 课程目录第4章 SSE核心原理

4. SSE 核心原理：密文索引构建与陷门生成机制

说起可搜索加密（SSE），很多人第一反应就是“在密文上做搜索”。听起来很酷，对吧？但要把这玩意儿落地，核心就两件事：怎么把索引藏起来，以及怎么让服务器拿着你的“钥匙”去查。

我刚开始接触 SSE 时，总觉得这跟普通加密搜索没啥两样。直到在一次企业邮件归档项目里，需要让服务器能在不解密的情况下检索几百万封加密邮件……嗯，那次经历让我彻底搞懂了索引和陷门的分量。

先说索引。明文搜索里，倒排索引是标配：每个关键词后面跟一串文档 ID。但在 SSE 里，你不能直接这么干。服务器不能看到文档 ID 本身，否则就泄露了信息。

那怎么办？把关键词和文档 ID 都藏起来。具体做法分三步：

关键词加密：用伪随机函数（PRF）把关键词映射成一个固定长度的“标签”。常见的做法是 tag = F(k, keyword)。注意，这里用的是确定性的加密——同一个关键词永远生成同一个标签。为什么？因为要保证搜索时能精确匹配。
文档 ID 加密：每个文档 ID 用对称加密算法（比如 AES）加密。加密后的结果就是 enc_id。
构建映射：把标签和加密后的文档 ID 列表一一对应。形式可以是 {tag1: [enc_id1, enc_id2, ...], tag2: [enc_id3, ...]}。

我的经验：关键词加密一定要用 PRF，别用哈希。哈希虽然快，但无法保证“陷门不可区分性”。我在项目里吃过这个亏——用 SHA-256 做关键词映射，结果被审计出安全性漏洞。后来老老实实换成了 HMAC-SHA256，配合独立密钥，才过审。

构建好的密文索引大概长这样（伪代码）：

// 明文倒排索引
{"alice": [doc1, doc2], "bob": [doc3]}

// 密文倒排索引（经过加密后）
{
  "a3f8b2...": ["0x1A2B...", "0x3C4D..."],
  "e7c1d9...": ["0x5E6F..."]
}

你想想看，服务器拿到这个密文索引后，既不知道 a3f8b2... 对应什么关键词，也看不懂 0x1A2B... 是什么文档。但它知道一件事：这个标签后面跟了一串加密后的文档 ID。——这就够了。

索引建好了，接下来用户要搜索。你不能直接把关键词发给服务器，得给它一个陷门（Trapdoor）。

什么叫陷门？说白了，就是用户用自己持有的密钥，把搜索关键词加密成一段“只有服务器能用来匹配索引”的密文。服务器拿着这个陷门，在密文索引里一比对，就能找到对应的加密文档 ID。

陷门生成的过程通常这样：

陷门生成公式（常用方案）：

trapdoor = F(key, keyword)
其中 F 是伪随机函数，key 是用户密钥，keyword 是搜索词

注意看，陷门和索引里的标签用的是同一个 PRF，同一个密钥。这样设计的好处是：服务器收到陷门后，只要在密文索引里查找 trapdoor == tag 的条目就行了。完全不需要解密！

曾经踩过的坑：当用户需要多关键词搜索时（比如“alice AND bob”），你不能简单地把两个陷门直接拼在一起发过去。如果服务器能暴力组合测试，就可能导致统计泄露。我记得在做一个多关键词 SSE 实现时，就因为这个设计缺陷导致搜索模式泄露，不得不重新设计协议。

具体到实现，陷门生成的步骤大致如下：

整个过程，服务器始终处于“半盲”状态：它能操作数据，但看不懂数据。这就是 SSE 的精髓。

上面讲得有点碎，我画张图把整个流程串起来。你盯着看一分钟，保证豁然开朗。

这张图里，我特意把“陷门生成”放在了搜索流程的核心。你注意到没有，客户端生成陷门和构建索引时用的是同一把钥匙、同一个算法。服务器端要做的就是匹配——这活儿简单又安全。

我个人习惯在实现时，把 PRF 的密钥和对称加密的密钥分开管理。为什么？因为 PRF 的密钥泄露了，攻击者就能伪造任意陷门，等于整个系统被攻破。分开之后，即使对称加密密钥泄露，也只是文档被解密，搜索模式还安全。

项目实践总结：

组件	算法选型（常用）	密钥用途	安全要求
关键词加密（PRF）	HMAC-SHA256 / AES-CMAC	生成索引标签 & 陷门	必须不可逆，确定性输出
文档 ID 加密	AES-CTR / AES-GCM	加密文档标识符	需要语义安全（IV 随机化）
陷门传输	TLS 安全信道	保护陷门不被窃听	防重放攻击、抗中间人

讲到这里，密文索引和陷门生成的核心原理应该清楚了。但我还得补充几个实际项目中容易踩的坑：

确定性加密的代价：关键词加密必须是确定性的（同一个关键词永远生成同一个标签），但这也带来了频率泄露。如果某个关键词出现的文档特别多，攻击者就能通过标签列表的长度推测出高频词。在我的项目里，应对方式是加虚拟文档来填充索引，让每个标签对应的文档数量接近一致。
陷门大小的选择：陷门太大会增加网络开销，太小又可能影响安全性。一般建议使用 128 比特（16 字节）或 256 比特（32 字节），取决于 PRF 的输出长度。我自己习惯用 128 位，性能和安全的平衡性最好。
索引更新时的陷门处理：如果你需要动态更新索引（比如新增文档），要小心更新陷门的设计。我之前做过一个动态 SSE 系统，更新时直接追加新的标签到旧列表里，结果被审计出插入模式泄露。后来改用带加密计数器的方案才解决。

曾经踩过的另一个坑：多用户场景下，不能让所有用户共享同一个 PRF 密钥。否则一个用户的恶意行为会导致整个系统的陷门可伪造。正确的做法是每个用户分配独立的密钥，或者使用基于属性的可搜索加密（ABSE）。不过那是更高级的课题了，咱们先打好基础。

最后总结一下：密文索引构建就是把明文倒排索引“加密化”的过程，核心工具是 PRF 和对称加密；陷门生成则是用同样的 PRF 把搜索词变成“服务器能匹配但看不懂”的密文。这两者共同构成了 SSE 的基石——服务器能帮用户搜索，但始终看不到搜索内容和文档内容。

这个原理听起来简单，落地时却有很多细节。如果你在实现过程中遇到具体问题，回头看看这张图，应该能帮你理清思路。