密文检索基础：对称可搜索加密原理、非对称可搜索加密归纳总结
说实话，刚开始接触密文检索的时候，我也觉得这玩意儿有点反直觉。
数据都加密成一堆乱码了，你凭什么还能在里面搜关键词？
但仔细想想——如果不解决这个问题，数据上云就只剩"存"和"取"两件事，审计、分析、合规检索全得跪。
我在几个DLP项目里都踩过这个坑：日志加密存进数据库，等需要查某条敏感记录时，只能全量拉回来解密后再搜。几十TB的数据，搜一次够你喝一壶的。
后来才意识到，可搜索加密（Searchable Encryption，SE）才是正解。
这一章，咱们把对称可搜索加密和非对称可搜索加密掰开揉碎聊清楚。
1.1 为什么需要密文检索？
先看一个典型场景：
你把审计日志用AES加密，上传到云存储。过两天安全团队说——"帮我查一下上周IP为10.0.1.5的所有登录失败记录"。
你怎么办？下载全部密文→解密→扫数据→返回结果。数据量大了以后，这流程跑一次就想骂人一次。
密文检索要解决的问题就是：在不解密的情况下，直接对加密数据进行关键词或模式匹配。
核心价值：
- 数据全程加密，服务方无法窥探明文
- 检索效率远高于"全量解密再搜索"
- 满足GDPR、等保、SOX等合规要求
你想想看，如果DLP系统本身就能在密文上做审计日志检索，那合规审计就不再是"事后补票"，而是真正的"全程可验"。这也是为什么可搜索加密在零信任架构里越来越被看重。
1.2 对称可搜索加密（SSE）
对称可搜索加密，简称SSE。它是最早被广泛研究的密文检索技术。
核心思路很简单：数据拥有者用对称密钥加密数据，同时构建一个加密索引。搜索时，用同一把密钥生成一个陷门（trapdoor），服务器拿陷门去查索引，就能知道哪些密文包含目标关键词。
核心流程
- 初始化：数据拥有者生成对称密钥 K
- 加密数据 + 建索引：对每条记录加密，同时提取关键词构建加密索引
- 生成陷门：搜索时，用密钥 K 和关键词 w 生成陷门 Tw
- 检索：服务器用 Tw 扫描索引，返回匹配的密文标识
- 解密：数据拥有者用 K 解密返回的密文
我在第一个SSE项目里犯过一个低级错误——把关键词直接AES加密后当索引用。结果每次搜索都是全索引遍历，几百万条记录跑一次要十几秒。
后来改用倒排索引 + 伪随机函数的经典结构，才把单次搜索压到毫秒级。这个坑，你记住就行。
我的建议：
生产环境选SSE方案时，优先看它是否支持亚线性搜索。线性扫描虽然实现简单，但数据量过百万就开始吃力了。我习惯用基于倒排索引的SSE-1/SSE-2方案，效率最稳。
一个简单的SSE索引构建伪代码
// 关键词 -> 包含该关键词的文档ID列表
Map<String, List<DocID>> invertedIndex = buildInvertedIndex(documents);
// 加密倒排索引
Map<String, List<byte[]>> encryptedIndex = new HashMap<>();
for (String keyword : invertedIndex.keySet()) {
// 用伪随机函数生成索引标识
String indexKey = PRF(K, keyword);
List<byte[]> encryptedDocIds = new ArrayList<>();
for (DocID docId : invertedIndex.get(keyword)) {
// 用密钥加密文档ID
encryptedDocIds.add(AES_encrypt(K, docId.toBytes()));
}
encryptedIndex.put(indexKey, encryptedDocIds);
}
// 搜索时生成陷门
String trapdoor = PRF(K, searchKeyword);
List<byte[]> result = encryptedIndex.get(trapdoor);
注意看，PRF（伪随机函数）是SSE安全性的基石。
攻击者拿不到密钥，就无法从索引标识反推出原始关键词。这也是SSE能抵抗"选择明文攻击"的原因。
警告：
SSE的安全性假设是"服务器半诚实"——它会按协议执行，但可能偷看数据。如果你的威胁模型里有恶意服务器篡改结果，那需要额外加可验证机制。我在金融DLP项目里就因为没加验证，被合规团队怼回来一次。后来补了MAC校验，才算过审。
1.3 非对称可搜索加密（ASE/PEKS）
非对称可搜索加密，圈里更常叫PEKS（Public-key Encryption with Keyword Search）。
它和SSE最大的区别就一句话：用公钥加密，用私钥生成陷门。
这玩意儿在"多用户写入、单一用户搜索"的场景下特别好使。
比如：多个审计探头把日志加密写入中央存储，只有审计官能搜索。如果用SSE，你得把对称密钥分发给每个探头——密钥分发本身就是个安全隐患。
PEKS 的工作流程
- 密钥生成：接收方生成公私钥对 (PK, SK)
- 加密：发送方用公钥 PK 加密数据，同时为每个关键词生成 PEKS 密文
- 生成陷门：接收方用私钥 SK 和关键词 w 生成陷门 Tw
- 检索：服务器用 Tw 检查每个 PEKS 密文是否匹配
- 解密：接收方用私钥 SK 解密匹配的密文
我第一次看 Boneh 等人的PEKS时，觉得双线性配对这东西好抽象。
后来在数据共享平台上落地才发现：PEKS最大的痛点不在理论，而在效率——一次搜索要对每个密文做一次配对运算，数据量上去以后真吃不消。
| 特性 | SSE（对称） | PEKS（非对称） |
|---|---|---|
| 密钥体系 | 单密钥，分发困难 | 公私钥对，分发方便 |
| 搜索效率 | 快（亚线性或线性） | 慢（线性 + 配对运算） |
| 写权限 | 有密钥就能写 | 有公钥就能写 |
| 典型场景 | 个人数据、单用户存储 | 多用户写入、中心化审计 |
| 安全性基础 | PRF / 伪随机置换 | 双线性配对 / 哈希 |
| 成熟度 | 高（已有工业级实现） | 中（学术方案多，落地少） |
选型建议：
如果你的DLP审计日志是单点采集、单点审计，SSE 足够了，效率高、成本低。
如果是多点采集、统一审计，或者涉及多方数据共享，建议上 PEKS。我目前在做的审计日志平台就是混合用的——本地缓存用SSE，跨域传输用PEKS。
1.4 对称 vs 非对称：一张图看清知识体系
下面这张SVG把本章的核心知识结构串了起来。你跟着箭头走一遍，心里就有谱了。
本章小结：
- SSE 的核心优势是效率，适合数据量大、密钥可控的封闭环境
- PEKS 的核心优势是密钥管理，适合多写入方、单一审计方的开放环境
- 选择哪种方案，先问自己三个问题：谁写数据？谁搜数据？数据量级多大？
一个血的教训：
我曾经在一个跨组织审计项目中，为了追求效率强行上了SSE。结果密钥分发协议写了三版都没过安全评审——因为每个审计探头都得存一份相同的对称密钥，泄露风险太大。
后来换用PEKS，虽然搜索慢了30%，但密钥管理一下子清爽了。所以别只看benchmark，先看你的信任模型。
好，密文检索的两种基础范式就聊到这里。你只要把SSE和PEKS的流程、优劣、场景对应关系吃透，后面再讲复杂查询、动态更新、可验证检索时，就不会觉得飘了。