二、可搜索加密基础：SSE 与 ASE 对比

这一章，咱们聊点实在的——可搜索加密。说白了就是：数据加密存到服务器后，怎么还能搜索？你可能会想，解密再搜不就完了？那还要加密干嘛。所以这里需要一套特殊的加密方案，让服务器能在不解密的情况下，完成搜索操作。

嗯，我自己第一次接触这个领域时，也有点懵。当时做一个医疗数据共享项目，患者病历加密存在云上，医生需要按关键词检索。传统做法只能全部下载解密再搜，数据量一大根本行不通。后来我才发现，这类问题早有成熟的解法，就是可搜索加密。

2.1 可搜索加密的核心思想

可搜索加密（Searchable Encryption，SE）的核心思路，其实很朴素：

• 数据端：对明文数据构建密文索引，再一起加密上传
• 查询端：用查询关键词生成一个“陷门”（trapdoor），发给服务器
• 服务器：用陷门去匹配密文索引，返回匹配结果

服务器全程看到的都是密文。它不知道你搜的是什么，也不知道索引里存的是什么，但能准确返回你需要的数据。

根据加密机制的差异，可搜索加密分成两大类：对称可搜索加密（SSE）和非对称可搜索加密（ASE）。下面我着重对比这两种方案。

2.2 对称可搜索加密（SSE）

对称可搜索加密，顾名思义，加密和解密用的是同一个密钥。这个密钥由数据拥有者牢牢掌握，其他人拿不到。

在项目中我习惯用 SSE 的场景是这样的：所有数据都在我的掌控之下，我不需要别人帮我生成密文或陷门。典型的例子就是本地文件加密搜索，或者企业内部文档库的密文检索。

SSE 的工作流程

1. 初始化：数据拥有者生成对称密钥 K
2. 构建索引：对文档集合中每个文档，提取关键词，用 K 加密关键词生成索引项
3. 加密文档：用对称加密算法（如 AES）加密文档本身
4. 上传：将密文文档 + 密文索引发送给服务器
5. 查询：用户想搜关键词 w，用 K 生成陷门 T = Enc(K, w) 发给服务器
6. 匹配：服务器遍历密文索引，如果某索引项与 T 匹配，返回对应文档 ID

这个过程你想想看，服务器每次都要遍历整个索引。文档多了，效率就是个大问题。所以我建议在 SSE 实现时，通常会用一些高效的数据结构来加速，比如倒排索引或布隆过滤器。

// 伪代码示例：SSE 陷门生成与匹配
// 假设使用 HMAC 作为伪随机函数

function generateTrapdoor(key, keyword):
    // 用 HMAC 生成固定长度的陷门
    return HMAC_SHA256(key, keyword)

function searchIndex(trapdoor, encryptedIndex):
    // 遍历倒排索引列表
    for each entry in encryptedIndex:
        if entry.key == trapdoor:
            return entry.docIDs
    return empty list

2.3 非对称可搜索加密（ASE，又称 PEKS）

非对称可搜索加密，也叫公钥可搜索加密（Public Key Encryption with Keyword Search, PEKS）。它用的是一对密钥：公钥用于加密，私钥用于生成陷门。这个概念在 2004 年由 Boneh 等人提出来，当时我记得是在一次安全会议上听到，觉得思路实在太巧妙了。

ASE 适合什么场景？说白了，就是别人要给你发加密数据，还要让你能搜索。比如邮件系统：别人用你的公钥加密邮件和关键词，你收到后用私钥就能检索。整个过程不需要共享密钥。

ASE 的工作流程

1. 初始化：接收者生成密钥对 (PubKey, PrivKey)
2. 发送者加密：发送者用 PubKey 对关键词 w 加密，得到密文索引，连同加密文档一起发送
3. 接收者查询：接收者想搜 w，用 PrivKey 生成陷门 T
4. 服务器匹配：服务器运行测试算法 Test(T, encryptedIndex)，判断是否匹配
5. 返回结果：如果匹配，返回对应文档密文

这里有个难点：ASE 的测试算法通常是基于双线性对的，计算开销比 SSE 大很多。我有次在安全聊天系统里试过 ASE，查询响应时间明显比 SSE 长，这算是一个避坑点。

2.4 SSE 与 ASE 的全面对比

下面这个表格是我个人归纳的对比，你做一个技术选型时可以直接参考。

对比维度	SSE	ASE / PEKS
加密机制	对称加密（同一密钥）	非对称加密（公私钥对）
密钥管理	需要共享密钥，密钥分发是难点	公钥公开，私钥保密，分发简单
计算开销	低（对称加密 / 哈希运算）	高（双线性对 / 模幂运算）
查询效率	高，适合高频检索	中等，单次查询更耗时
适用场景	单一用户、内网文档、本地加密搜索	多发送者、邮件系统、加密社交
密文长度	较短，索引紧凑	较长，每个关键词加密后膨胀
代表性方案	SWP, Curtmola, Cash	Boneh-Franklin, BDOP

2.5 SSE 与 ASE 的体系关系图

我画了一张图，把这个知识体系串起来。你可以看到这两种方案在整个可搜索加密体系中的位置和关联。

2.6 本章小结

到这里，可搜索加密的两大分支就讲清楚了：

• SSE：对称密钥，单用户场景，效率高，密钥管理麻烦
• ASE：公私钥对，多发送者场景，安全性高，计算开销大

做技术选型时，你可以先画出你的系统架构图，看数据流向是单一的还是多源的，再做决定。下一章咱们会深入 SSE 的索引结构与查询优化策略，到时候很多概念会自然串起来。