📚 课程目录第4章对称可搜索加密（SSE）原理

对称可搜索加密（SSE）原理：构建加密索引、生成搜索令牌

好了，我们进入正题。对称可搜索加密，简称 SSE，是密文检索里最经典、最务实的一派。说白了，它解决的是这样一个问题：你有一堆私密数据，加密后存到了云上，但你还想按关键词搜索，怎么办？

最简单的办法——每次搜索都把所有密文下载下来，解密，再在本地搜一遍。我早期做原型时就是这么干的，结果数据量刚过 100MB，网络延迟和带宽就把我整崩溃了。这显然不是出路。

SSE 的核心思路就一句话：把搜索能力“嵌入”到密文里去。具体怎么做？两步走：先给数据建一个加密的索引，再为每个搜索词生成一个令牌（）。搜索时，你把令牌交给服务器，服务器拿着令牌去匹配加密索引，返回匹配的结果。整个过程，服务器看不到明文关键词，也看不到明文数据。

SSE 的两个关键动作：

加密索引构建：将文档集合的关键词映射关系，加密后存储。
搜索令牌生成：从明文搜索词出发，利用密钥生成一个不可逆的令牌。

嗯，这里要注意：加密索引和搜索令牌必须是用同一个密钥生成的。否则，令牌就没办法匹配索引了。这是整个系统的信任基石。

加密索引：怎么给数据做一个“加密版目录”？

先想想传统明文搜索怎么做。你有一个倒排索引：关键词 → 包含该词的文档 ID 列表。搜索时，直接查这个映射表，拿到结果。现在的问题变成：这个映射表必须加密，而且要能支持令牌匹配。

我个人的习惯，是把加密索引比喻成一个加了密的电话簿。电话簿本身是乱码的，但你有一个特殊的“解码眼镜”（也就是令牌），戴上它，你就能看出这个乱码里哪些条目是你要找的。但别人没这个眼镜，看到的还是一堆乱码。

常见的加密索引结构有两种：

索引类型	原理简述	我见过的坑
基于布隆过滤器	用一个位数组 + 多个哈希函数表示集合成员关系	误判率不好控制，参数调不对会出大问题
基于倒排索引	对每个关键词构建加密映射表，key 是关键词的哈希值	泄漏访问模式，容易被统计攻击

为什么布隆过滤器适合做索引？因为它占空间小，而且支持快速的成员检测。你想想看，服务器不需要知道完整的文档列表，它只需要知道“这个令牌对应的关键词，在不在这个文档里”。恰好，布隆过滤器就是干这个的。

我在项目中遇到过用倒排索引的场景。当时需要支持百万级文档的检索。倒排索引的构建逻辑大概是这样的：

// 加密索引构建伪代码
for each document doc in collection:
    for each keyword kw in extractKeywords(doc):
        // 用密钥加密关键词
        encryptedKw = HMAC(key, kw)
        // 将文档ID加入该关键词对应的加密列表
        invertedIndex[encryptedKw].append(encrypt(doc.id))
        
// 最后整个 invertedIndex 需要做二次加密或混淆处理
storeEncrypted(invertedIndex)

这段代码看着简单，但有两个关键点：第一，HMAC 的密钥必须是安全保密的；第二，直接存储上面的结构会泄漏访问模式——同一个关键词的文档列表长度不变，攻击者能看出来哪些文档包含了相同的关键词。所以，实际工程中还要做填充或混淆来抵抗这种攻击。

我曾经踩过的坑： 忘记对文档列表进行均匀填充。结果攻击者通过观察不同关键词对应的文档数量，就能猜出哪个是冷门词、哪个是热门词，直接导致部分信息泄漏。后来我强制要求所有关键词的文档列表长度统一对齐到最大值，才算堵上这个漏洞。

搜索令牌：把搜索词变成“一次性钥匙”

搜索令牌的生成逻辑，和索引构建是镜像对称的。用户输入一个搜索词，系统用同一个密钥生成令牌。服务器拿到令牌后，用它在加密索引里做匹配。

这里要强调一点：令牌生成必须是确定性的。也就是说，同样的关键词，每次生成的令牌必须一样。否则索引里存的 key 和令牌对不上，就没法查了。但这也带来一个问题：重复查询会暴露模式。

你的搜索令牌长什么样？看代码：

// 生成搜索令牌
function generateToken(key, keyword):
    // HMAC 是确定性加密，相同输入总是相同输出
     = HMAC_SHA256(key, keyword)
    return base64_encode()

// 服务器端匹配
function search(encryptedIndex, ):
    // 直接用  作为 key 去查加密哈希表
    if  in encryptedIndex:
        return decryptList(encryptedIndex[])
    else:
        return []

你看，搜索过程就是一个哈希表查表操作。O(1) 的复杂度，性能非常棒。我在做第一个 SSE 原型时，就特别喜欢这个特点——它把密文搜索退化成了找钥匙开锁的活儿。

我的一个小建议： 生成的令牌建议用 base64 编码成可打印字符串，方便存储和传输。另外，HMAC 的 key 要定期轮换。轮换 key 意味着需要重建索引，但这是值得的安全付出。

SSE 的核心流程，一张图说明白

我把整个 SSE 检索流程画了一张图。你仔细看，就三部分组成：数据拥有者构建索引、数据拥有者生成令牌、服务器执行匹配。

这张图里，蓝色的节点代表数据拥有者的操作——建索引。绿色的节点代表数据拥有者的另一个操作——生成令牌。紫色节点是服务器干的事——用令牌去匹配。你发现没，服务器始终没碰过明文，这是核心。

几种 SSE 方案的对比，你选哪种？

SSE 不是一个单一的算法，它是一个家族。根据安全强度和性能，常见的有这么几种：

方案	安全级别	搜索效率	我什么时候会选它
SSE-1（确定性）	低（泄漏搜索模式）	极高	数据不敏感，或已做假数据填充
SSE-2（静态）	中（抗选择关键词攻击）	高	大多数生产场景，平衡安全与性能
SSE-3（动态）	高（支持增删改）	中等	需要频繁更新数据集的场景

我记得有一次做项目选型，对方坚持要最安全的方案。我直接问：你的数据多久更新一次？他说一天一次。那用 SSE-2 就好，别上动态方案，没必要把性能吃掉。

特别提醒： SSE 的安全模型里有一项叫“访问模式泄漏”。服务器虽然不知道你说的是什么词，但它能看到哪些文档是同一个关键词查出来的，也能看到搜索的顺序和频率。在高安全场景里，这是需要认真对待的威胁。解决思路有：引入 ORAM（不透明随机访问存储器）或 Padding 技术。

构建索引时，还要注意这个细节

很多初学者会忽略一个问题：加密索引应该存在哪里？存在服务端，还是客户端？

存在客户端：每次搜索前，客户端把加密索引发给服务器。好处是索引更新在本地完成，坏处是每次搜索都传一遍索引，带宽爆炸。
存在服务端：索引一次性上传，之后搜索只传一个小令牌。高效，但第一次建立索引时会稍重。

我个人的建议是：除非有极端隐私要求，否则把加密索引放在服务端。这是工程上最顺畅的做法。你想想看，你的目的就是把压力卸给服务器，如果索引还留在本地，那每次搜索都要拉一大包数据，和最初的全量下载有啥区别？

好，讲到这里，SSE 的索引构建和令牌生成就讲清楚了。接下来你会看到，这些底层原理会如何落地成 SDK 里的具体接口。不过那是后话了。