一、密文索引概述

大家好，我是这门课的主讲。先聊个实在的——密文索引，说白了就是让你能在不解密的情况下检索加密数据。听起来有点玄乎？我刚开始接触这个方向时也这么想。直到有一次，帮一个金融客户做数据合规项目，他们要求所有用户隐私数据必须全程加密存储，但业务方还想要模糊搜索……嗯，那会儿我才真正意识到，可搜索加密不是学术玩具，是实实在在的生产力工具。

1.1 可搜索加密的定义

可搜索加密（Searchable Encryption, SE）是一种密码学原语。它允许数据拥有者将加密后的数据（密文）和对应的索引一起交给服务器，服务器可以在不解密的情况下，根据用户发来的「陷门」进行搜索，返回匹配的密文。

我习惯把它拆成三个角色：

• 数据拥有者：加密文档，构建索引，上传。
• 服务器：存储密文+密文索引，执行搜索操作。
• 用户：生成陷门（也就是搜索令牌），发送给服务器。

整个过程，服务器从来看不到明文。这就是可搜索加密的魔力所在。

1.2 索引类型：对称 vs 公钥

可搜索加密根据密钥体系分成两大类。面试时这个点问得最多，我带你捋清楚。

1.2.1 对称可搜索加密（SSE）

对称可搜索加密，加密和解密用的是同一个密钥。效率特别高，适合单用户或信任的多用户场景。

我自己在实际项目中几乎都用 SSE。为什么？因为快。我记得有一次在 PB 级日志系统中做加密索引，如果换成公钥方案，光密钥交换就够折腾的。SSE 配合倒排索引，搜索时只需 O(1) 的令牌匹配，爽。

主要特点：

• 效率高：对称加密运算快，索引结构轻量。
• 搜索代价小：通常是 O(n) 或亚线性。
• 密钥管理简单：单用户场景下很舒服。
• 局限性：不支持灵活的布尔查询，表达力有限。

1.2.2 公钥可搜索加密（PEKS）

公钥可搜索加密，用公钥加密，用私钥生成陷门。支持多用户写入，单用户搜索，或者多用户互相搜索。

你想想看，如果是一个医疗数据共享平台，多个医院要加密上传病历，但只有授权的医生才能搜索——这时 SSE 就不行了，因为无法让多个数据拥有者共享同一个对称密钥。PEKS 就登场了。

主要特点：

• 多用户支持：任意用户可用公钥加密数据。
• 搜索更灵活：可以扩展支持更复杂的查询。
• 性能开销大：双线性配对运算很慢，索引体积也大。
• 安全模型更复杂：需要处理恶意服务器攻击。

对比维度	SSE	PEKS
加密方式	对称密钥（AES等）	公钥密码（双线性对等）
搜索速度	毫秒级（线性/亚线性）	秒级（配对运算瓶颈）
多用户支持	受限（需密钥分发）	原生支持
索引体积	小（可压缩）	大（常含公钥组件）
典型场景	个人云盘、内部日志	医疗共享、金融审计

1.3 性能评估指标

面试官不会只问你「SSE 和 PEKS 哪个快」。他们会追问：具体快多少？代价是什么？我整理了一套衡量指标，你在回答时按这个框架走，显得特别专业。

1.3.1 计算开销

• 索引构建时间：从原始数据生成索引所花的时间。
• 陷门生成时间：用户生成搜索令牌的耗时。
• 搜索执行时间：服务器匹配索引并返回结果的时间。
• 解密时间：客户端解密搜索结果的时间。

我习惯把前三个作为核心指标。解密时间通常不是瓶颈，因为匹配到的文档数一般不多。

1.3.2 存储开销

• 索引大小：密文索引占用的存储空间。
• 密文扩展率：索引大小 / 原始数据大小。
• 陷门大小：一次搜索需要的令牌体积。

你想想看，一个倒排索引在明文下可能只有 10% 的膨胀率，但加密后可能膨胀到 2-5 倍。面试时如果你能说出具体的膨胀倍数，面试官会觉得你有实操经验。

1.3.3 通信开销

• 轮询次数：搜索过程需要几次网络交互。
• 每次传输体积：陷门、结果集、更新操作的流量。

我的经验是，很多方案在学术里看起来很漂亮，但轮到通信轮数的时候直接崩。比如有些方案需要 2-3 轮交互才能完成一次搜索——这在局域网里还能忍，但在跨数据中心场景下，延迟直接翻倍。

1.3.4 更新开销

• 插入/删除/修改代价：动态更新索引时的性能。
• 是否需要重建索引：静态方案每次更新都得重来。

1.4 知识结构总览

下面这张图把这章的核心关系串起来了。仔细看看，面试时脑子里大概就有框架了。

嗯，这张图其实已经把可搜索加密的选型路径画清楚了。面试被问到「你如何设计一个密文索引系统」时，你可以顺着这个图讲：先明确场景（单用户 vs 多用户）→ 选 SSE 还是 PEKS → 再挑性能指标做权衡。有条理，不慌乱。