3. 可搜索加密技术分类
在云端密文检索平台中，可搜索加密（Searchable Encryption, SE）解决的是同一个核心矛盾：数据以密文形式存放在不可信服务器上，但用户仍希望按关键词检索。不同方案在“谁能加密、谁能检索、谁能解密、如何授权”这四个问题上给出不同答案，由此形成三条主流技术路线：对称可搜索加密（SSE）、公钥可搜索加密（PEKS）以及属性基关键词搜索（ABKS）。理解它们的差异，是后续架构选型与工程落地的前提。
一、三类方案的本质区别
对称可搜索加密（SSE）使用同一把对称密钥完成文档加密与陷门（trapdoor）生成。数据拥有者用密钥为每个关键词生成索引项（如关键词哈希与文档标识的映射），检索时用同一密钥生成关键词陷门，服务器在密文索引上匹配并返回命中文档标识。SSE 的典型代表是正向索引与倒排索引结构，其优势是速度快、索引小，适合海量文档；代价是密钥分发与撤销较难，检索方通常需要持有密钥，多用户场景需要额外设计。
公钥可搜索加密（PEKS）由 Boneh 等人提出，使用公钥加密关键词、私钥生成陷门。发送方用接收方公钥为文档关键词生成密文索引，接收方用私钥生成陷门交给服务器检索。PEKS 天然支持“第三方加密、接收方检索”的非对称场景，例如邮件网关为收件人加密索引；但其计算开销大、索引膨胀明显，且早期方案不支持多关键词与布尔查询，工程中常需扩展。
属性基关键词搜索（ABKS）把属性基加密（ABE）与关键词搜索结合：密文与索引绑定到访问策略（如“部门=财务 AND 级别≥3”），用户私钥绑定属性集合，只有属性满足策略的用户才能生成有效陷门并解密结果。ABKS 适合一对多、细粒度授权的云共享场景，但策略匹配与双线性对运算带来更高延迟，策略设计也直接影响可用性。
二、关键维度对比
| 对比维度 | SSE | PEKS | ABKS |
|---|---|---|---|
| 密钥结构 | 单一对称密钥 | 公钥加密、私钥陷门 | 属性私钥 + 策略 |
| 加密方 | 数据拥有者 | 任意持有公钥方 | 数据拥有者（策略绑定） |
| 检索方 | 持密钥者 | 持私钥的接收方 | 属性满足策略的用户 |
| 授权粒度 | 粗（密钥级） | 中（用户级） | 细（属性/策略级） |
| 典型开销 | 低，毫秒级 | 中高，双线性对 | 高，策略匹配 + 对运算 |
| 多关键词/布尔 | 易扩展 | 需专门构造 | 需结合策略表达 |
| 适用场景 | 单租户、海量文档 | 邮件、第三方写入 | 云共享、多用户细粒度 |
三、选型决策与工程落地
选型不应只看“安全性高低”，而应回到业务约束。可以按以下顺序判断：第一，谁产生密文？如果只有数据拥有者自己写入，SSE 足够；如果允许第三方（如邮件网关、IoT 设备）写入，则必须用 PEKS 或 ABKS。第二，检索授权有多细？若只需“有密钥就能查”，SSE 最简；若需要按部门、角色、等级控制，ABKS 更合适。第三，性能预算？SSE 单次检索通常在毫秒级，PEKS 与 ABKS 因双线性对运算可能达到数十毫秒甚至更高，需评估 QPS 与索引规模。
以一个企业云盘为例：假设有 50 万份文档，平均每份 20 个关键词，倒排索引约 1000 万条索引项。若采用 SSE，使用 HMAC-SHA256 生成索引项，单条索引 32 字节，索引总量约 320 MB，检索时服务器只需做哈希匹配，实测（示例环境）单次查询约 3～8 ms。若改用 PEKS，每个关键词密文约 256 字节，索引膨胀到约 2.5 GB，且每次匹配需双线性对运算，单次查询可能升至 30～80 ms。若再叠加 ABKS 的策略匹配，延迟还会增加。这个数量级差异直接决定架构：SSE 可支撑高并发检索，PEKS/ABKS 更适合低频、强授权的场景。
四、混合与演进思路
实际平台很少只用一种方案。常见做法是：用 SSE 构建高性能倒排索引，承担大部分关键词检索；用 ABKS 管理“谁有权生成陷门”，即把属性满足策略作为获取 SSE 密钥或陷门派生密钥的前提。这样既保留 SSE 的速度，又获得属性级授权。另一种思路是用 PEKS 处理跨域写入（如外部系统投递密文），再在域内转换为 SSE 索引。无论哪种组合，都要明确一个原则：陷门生成权限必须与解密权限分离设计，否则服务器一旦拿到陷门，可能推断出关键词分布，造成统计泄露。
综上，SSE、PEKS 与 ABKS 分别对应“对称高效”“非对称写入”“属性细粒度”三类需求。理解它们在密钥流向、检索路径与开销上的差异，才能在云端密文检索平台中做出可落地、可扩展的技术选型。