可搜索加密（SE）简介：SSE 与 PEKS 基本思想
聊到密文检索，绕不开一个核心问题：数据加密后，怎么还能搜？
直接解密搜？那加密还有啥意义。全量下载？网络和存储都扛不住。
所以就有了可搜索加密（Searchable Encryption, SE）。说白了，就是让服务器在密文上完成搜索，但不知道你搜的是什么，也看不到文档内容。这个概念听起来挺酷，但我第一次接触它时，脑子里全是问号——怎么做到？
为什么非得搞可搜索加密？
你想想，传统数据库里一个 SQL 查询，服务器能看清楚你的条件和数据。但合规要求上来了，数据必须加密存储，连索引都得加密。那查询怎么走？
- 方案一：把加密数据全拉下来，本地解密再搜——不现实，性能灾难。
- 方案二：服务器有私钥，边解密边搜——服务器权限太大，不安全。
- 方案三：可搜索加密。服务器持有一把“搜索钥匙”，它能判断匹配与否，但无法还原原文。
对称可搜索加密（SSE）
SSE 是最早成熟的一类方案，适用于数据拥有者和检索者是同一方（或共享密钥的环境）。它的核心思路：用对称密钥加密文档，同时构建一个加密索引。
怎么构建索引？ 简单来说，对每个关键词，算出一个 （伪随机函数输出），然后建立一个 → 文档标识符集合的映射。这个映射本身也是加密存储的。
- 数据拥有者用对称密钥，对关键词生成搜索陷门（trapdoor）。
- 把陷门传给服务器。
- 服务器用陷门在加密索引中查找匹配的文档 ID 列表。
- 返回这些文档的密文。
举个具体例子，假设我们用伪随机函数 F(K, w) 来生成 。K 是密钥，w 是想搜索的关键词。服务器预先存储了 → 加密后的文档 ID 集合。你给服务器一个 ，它就能通过查表找到对应的 ID 集合——注意，整个过程服务器不知道 K，所以它无法反推出 w，也无法生成其他关键词的 。
非对称可搜索加密（PEKS）
SSE 有个局限——密钥必须共享。如果你想让多个不同的人（比如多名医生）都能对加密数据发起搜索，传统 SSE 要分发对称密钥，很不安全。PEKS 应运而生。
PEKS 利用公钥密码系统。数据拥有者用接收者的公钥加密关键词，服务器存储公钥加密后的“可搜索密文”。接收者想搜索时，用自己的私钥生成关键词陷门。服务器能用这个陷门判断哪些可搜索密文匹配，但它无法伪造陷门（因为没有私钥）。
这种方案天然适合多写多读的场景：很多人可以往数据库里写入加密数据，只有持有私钥的人才能搜索。
| 维度 | SSE | PEKS |
|---|---|---|
| 加解密方式 | 对称密钥 | 公钥/私钥 |
| 密钥管理 | 密钥需共享，写者=读者 | 私钥仅读者持有，写者用公钥 |
| 搜索陷门生成 | 使用对称密钥 | 使用私钥 |
| 适用场景 | 个人云盘、内部搜索 | 多方写入、审计日志、邮件过滤 |
| 效率 | 较高（对称运算快） | 较低（公钥运算贵） |
但 PEKS 也有代价。公钥运算比对称加密慢一个数量级。而且大部分 PEKS 方案对陷门和密文的大小控制不如 SSE 精细。我记得在一个网关项目中，PEKS 的单个搜索花了 50 毫秒，SSE 只要 0.1 毫秒——差了两个数量级。
SSE vs PEKS：怎么选？
- 单用户场景：SSE 就能满足，别给自己加戏搞 PEKS。
- 多写者、单读者：PEKS 天然适合。比如多个传感器加密数据，只有中央分析平台能搜。
- 多写者、多读者：需要属性基加密或混合方案，这已超出本章范围。
- 对性能敏感：先用 SSE，再考虑在上层包装密钥访问控制。
下面这张图可以帮你快速建立 SSE 和 PEKS 的整体流程印象。
安全性：永远别只看表面
很多新手以为“加密了”就万事大吉。其实可搜索加密有很多微妙的泄露风险。比如搜索模式（什么时候搜、搜多少次）、访问模式（哪些文档被命中）、甚至结果的大小都能泄露信息。
- 选择明文安全（IND-CPA）：基本要求，加密文本不能区分。
- 抗关键词猜测攻击：如果关键词空间很小（比如性别只有男/女），攻击者可以暴力枚举。PEKS 尤其脆弱——因为公钥公开。
- 前向安全：更新索引后，旧的陷门不能用于新文档。我曾见过产品因为没有前向安全，导致追加数据后被统计出增长规律。
SSE 和 PEKS 只是可搜索加密的基石。实际落地时，你往往需要组合使用：用 SSE 做主体索引，用 PEKS 做跨域授权。下一层的性能优化、更新策略、并发控制，我们会逐一拆解。