4. 可搜索加密技术简介
好，我们正式进入《密文检索SDK》的核心理论部分——可搜索加密。这名字听起来有点绕，说白了就是：数据是加密的，但我想在不解密的情况下，直接在上面做搜索。你想想看，这个场景在现实中太常见了。比如你把文件存到云端，云端能直接看你的文件内容吗？不能，因为加密了。但如果你要找某个文件，难道要把所有文件下载回来，解密了再搜？那效率就太低了。
我当年刚接触这个领域时，也觉得这是个“既要马儿跑，又要马儿不吃草”的活。直到我研究了相关的密码学构造，才发现其中的精妙之处。其实它并不是魔法，而是一套巧妙的「密码学游戏」。
4.1 核心思想：关键词密文索引
可搜索加密（Searchable Encryption, SE）的核心思想，是为每个文档生成一个加密的索引。这个索引里包含了一组「关键词-指针」对。注意，关键词本身也是加密的。
搜索时，用户会生成一个搜索令牌（）。服务端收到令牌后，就可以直接在加密索引上进行匹配，而无需解密索引本身。整个过程，服务端看不到原始关键词，也看不到文档内容。
核心约束：服务端只能知道「哪些加密文档包含了该搜索令牌」，但不能知道「令牌对应什么关键词」，更不能知道「文档内容是什么」。
我曾经在项目中见过一种错误的设计：有人试图在客户端先解密所有文档ID列表，再用明文关键词去匹配。这其实就失去了加密的意义。真正的可搜索加密，整个匹配过程必须在密文状态下完成。
4.2 两种主流方案
根据应用场景的不同，可搜索加密主要分为两类。我列个表，你一眼就能看明白。
| 特性 | 对称可搜索加密 (SSE) | 非对称可搜索加密 (PEKS) |
|---|---|---|
| 加密钥匙 | 数据拥有者和搜索者共享同一把对称密钥 | 用公钥加密，私钥搜索 |
| 应用场景 | 个人数据加密、企业内部数据搜索（你的云盘） | 邮件过滤、多人协作场景（有人给你发加密邮件） |
| 计算开销 | 低，通常使用伪随机函数和对称加密 | 高，依赖双线性对等复杂数学运算 |
| 典型特点 | 速度快，适合大规模数据 | 支持多用户写入，但搜索效率相对低 |
我们的SDK主要聚焦在对称可搜索加密（SSE）上。原因很简单：在我们涉及的密文检索场景中，数据拥有者通常也是搜索者。你上传加密数据，然后你自己去搜索它。如果是多人共享场景，我们会有其它机制处理，但底层的搜索算法核心仍然是SSE。
4.3 经典构造：反向索引 + 伪随机函数
我们来解剖一个经典的SSE构造。它依赖两个基本工具：伪随机函数（PRF） 和 加密的键值对映射表。
构建索引的伪代码大概是这样的：
# 伪代码：构建加密索引
# key: 伪随机函数的密钥
# doc_id: 文档的唯一标识
# keyword: 明文关键词
def build_index(key, keyword_doc_pairs):
# 1. 为每个关键词生成一个确定性密文标签
# 2. 将文档ID列表加密后，关联到该密文标签下
encrypted_index = {}
for keyword, doc_ids in keyword_doc_pairs.items():
# 生成标签：用PRF把关键词变成“不可读的”标签
= PRF(key, keyword)
# 存储：将整个文档ID列表加密后存入
# 注意：这里加密文档ID列表时，使用了另一个密钥
encrypted_list = encrypt_list(key, doc_ids)
encrypted_index[] = encrypted_list
return encrypted_index
# 搜索时的令牌生成
def generate_(key, keyword):
# 在搜索时，客户端用同样的PRF生成搜索令牌
return PRF(key, keyword)
# 服务端执行搜索
def search(encrypted_index, ):
# 服务端直接在索引查找这个令牌
if in encrypted_index:
return encrypted_index[] # 返回的是加密后的文档ID列表
else:
return []
为什么用伪随机函数？ 因为它保证了“确定性”。同一个关键词，在任何时候生成的PRF值都是一样的。这样服务器才能精确匹配。但又因为PRF的输出是伪随机的，攻击者无法从中推断出原文。
记得有一次，团队里有人质疑：“如果关键词是‘password’，PRF输出是固定的，那频率分析怎么办？” 好问题。我们确实需要额外的防频率分析机制，这个后面会讲到。
4.4 安全模型：不可区分性 (Indistinguishability)
我们如何衡量一个可搜索加密方案的安全性？业界公认的标准叫做「选择关键词攻击下的不可区分性」。名字很长，但核心就一点：攻击者即使能看到加密索引，并且他能猜测一些关键词（比如‘password’、‘attack’），他也无法区分索引里到底包含了哪个关键词。
我参与过一个安全审计项目，对方提交的方案声称“很安全”。但我发现他们的PRF密钥是固定的，而且没有加盐。攻击者只要枚举常见关键词，就能建立起「明文关键词 - 密文标签」的对照表。这就完全失效了。嗯，这里要特别提醒：PRF的密钥必须随机生成，而且不能硬编码在客户端代码里。
警告：关于泄露问题
任何可搜索加密方案都无法避免信息泄露。它会泄露：
- 搜索模式：同一个搜索令牌被搜索了多少次。
- 访问模式：哪些文档是被同一个搜索找到的。
这不是方案有漏洞，而是「可搜索」这个功能本身附带的。你在做安全评估时，必须把这一点作为风险点考虑进去。
4.5 本章知识图谱
下面这张图，我用它来串联整个可搜索加密的核心逻辑。从数据预处理到最终返回结果，每一步都依赖于密码学的精巧设计。
4.6 本章小结
可搜索加密不是单一技术，而是一套密码学工程实践。你需要记住几个核心点：
- 它让搜索操作在密文域上完成，安全与功能并存。
- 对称可搜索加密（SSE）是性能最好的方案，适合我们SDK的场景。
- 伪随机函数（PRF）是构建「搜索令牌」和「密文标签」的核心工具。
- 它并非零泄露，搜索模式和访问模式会泄露。这是你设计系统时必须评估的风险。