可搜索加密概论：问题定义、应用场景、安全性要求

要讲清楚可搜索加密，得先回答一个最直接的问题：你凭什么在密文上做搜索？

我第一次接触这个领域时，脑子里蹦出的第一个问题就是这个。你想，数据都加密了，服务器拿到手里就是一堆乱码。怎么知道哪条记录里包含"月薪"这个词？总不能把密钥给服务器吧，那加密就毫无意义了。

核心矛盾：加密与可搜索的悖论

传统的加密，说白了就是"一锁了之"。你把文件锁进保险箱，谁也别想看。但可搜索加密想做的是：

• 数据全程保持加密状态
• 用户只能搜索自己授权的关键词
• 服务器帮忙干苦力，但看不到原文

有点像你给管家一把特制的钥匙，这把钥匙只能打开某个单一抽屉，而且管家不知道这个抽屉里到底放了什么。我在项目中遇到过类似需求，用户希望把病历加密存到第三方云上，但又需要按"糖尿病"这样的关键词筛选患者。嗯，这就逼着你必须找到一种巧妙的加密方案。

一段代码说清问题边界

先看一个最简单的例子，感受一下核心流程：

// 服务端：加密数据 + 可搜索索引
tag = Enc(k, keyword)   // 生成关键词标签
EncryptedRecord = Enc(k, record) // 加密整条记录

// 用户端：生成查询陷门
trap = GenTrapdoor(k, "糖尿病")

// 服务端：执行匹配，返回结果
if (tag == trap) {
    return EncryptedRecord
}

你注意看，这个 tag 和 trap 都是用同一个密钥 k 算出来的。服务器拿到 trap 后，挨个比对 tag，如果相等就说明命中了。整个过程中，服务器不知道关键词是什么，只知道这两个值碰巧相等。

两种主流技术路线

具体怎么做？我习惯把它分成两派：

技术路线	核心做法	典型场景
对称可搜索加密	用对称密钥生成标签 + 陷门	单用户、本地设备 + 云盘
公钥可搜索加密	用公钥加密，私钥生成陷门	多用户、邮件路由、医疗共享

对称方案效率高，适合你一个人把数据存到云上。公钥方案支持别人给你发加密邮件，然后你能从中搜索。

我之前做过一个医疗数据共享项目，就是典型的公钥场景。医生A把患者记录用医院公钥加密，医生B在出差时用私钥生成陷门，查询"过敏药物"。服务器帮忙做匹配，但完全不知道医生B到底在查什么病。这点很重要，关乎医疗隐私合规。

应用场景：到底能用在哪儿？

不要觉得这只是学术玩具。这几年我见到的真实落地场景越来越多：

• 邮件网关过滤：邮件服务器只能在加密邮件中检索"紧急"、"会议"等关键词，但不知道邮件正文内容。
• 医疗数据共享：第三方平台存储加密病历，医生远程查询时仅暴露陷门，不暴露查询意图。
• 企业内部审计：合规部门需要搜索加密的财务日志，但日志管理员不想让审计部门拿到解密密钥。
• 文件去重 + 搜索：云盘先对文件做加密去重，用户再在去重后的密文集合中搜索个人文件。

安全性要求：你必须知道的风险

可搜索加密并不是"安全"的。你想想看，服务器虽然看不到原文，但能观察到一些额外的信息。这就引出了安全性定义的问题。

安全性等级	泄露给服务器的信息	适用场景
CPI‑1（仅密文安全）	只有加密后的数据 + 索引	防外部偷窥，防泄露数据库
CPI‑2（自适应安全）	另外暴露搜索模式——哪些查询是同一个关键词	大多数实际部署都至少需要这个等级
OPE / ORE	密文保持大小顺序	范围查询、排序查询

我说白了，很多里吹的"完美安全"基本不实用。真正的产品部署，大家都会做一个权衡：你能接受多少信息泄露，换取多少性能提升。

核心安全性指标速查

评估一个可搜索加密协议时，我会重点看这几个维度：

• 搜索模式泄露：服务器能否看出两次查询是否相同？
• 访问模式泄露：服务器能否知道哪些记录被命中了？
• 文档内容泄露：能否从索引推导出文档中关键词的位置、频率？
• 前向安全：添加新文档后，服务器能否通过已有查询陷门做回溯匹配？

你想想看，如果一个协议不满足前向安全，那么你新增一份文档后，攻击者用以前的查询陷门就能判断新文档是否包含对应关键词。这显然是不安全的。

一张图看懂本章知识体系

我把刚刚讲的核心概念画成一张流程结构图：