只泄露0.1%的文档,AI也能猜回近半加密搜索词

假设一家公司的文档全部加密，服务器只负责按加密关键词返回结果。正文看不到，搜索词也看不到，看起来已经足够安全。

可服务器还知道两件事：某次搜索命中了哪些加密文档，以及一共返回多少份。再给攻击者30份已知明文——在一个3万份文档的库里恰好是0.1%——这些痕迹就可能被重新拼成关键词。

USENIX Security 2026的一项研究显示，加入大模型生成的语义关系后，0.1%的已知文档足以在六组数据上正确恢复36%至49%的搜索词。被放大的不是密文本身，而是密文周围一直裸露的访问模式。

加密正文，为什么还会暴露查询

可搜索对称加密（SSE）要同时满足两个目标：服务器不知道正文，但仍能快速找出包含某个关键词的文档。为了避免每次把整个数据库下载到本地，服务器通常会看到返回了哪些加密文档、相同查询是否再次出现，以及结果数量。

这些分别构成访问、搜索和容量模式。单看一次查询，它们像没有内容的脚印；查询积累起来，哪些词经常出现在同一批文档中、哪些词结果很多，就会形成统计指纹。

论文《Your Keywords Know Each Other》研究的是一种被动攻击：服务器不篡改查询，持续观察这些模式，同时已知目标库0.1%至1%的少量明文。明文可能来自旧备份、迁移残留、内部访问或部分泄露。

所以，0.1%不能被简化成“只看一点密文就能破解”。攻击还需要少量真实明文、可观察的查询结果关系和固定的关键词集合。少任何一项，论文中的恢复率都不能直接套用。

传统方法会在已知文档中统计关键词共现。例如“预算”和“会议”常出现在同一批邮件里，就把这种关系拿去匹配加密侧的查询模式。问题是样本太少时，大多数词根本没有共同出现，共现矩阵近乎空白。

研究团队提出的Whisper先找出少量高置信度匹配，作为锚点；再让LLM合成同类文本，补充可能的词语搭配；预训练词嵌入同时提供“哪些词在语义上接近”的软信号。末端匹配不是逐个贪心猜词，而是一次全局求解，避免前面的错误一路传下去。

这里的大模型没有读取目标加密库，也不需要记住那批文档。它提供的是通用语言经验：预算更可能和财务、会议、审批相连，而不是与完全无关的词随机组合。攻击者把这种经验与真实访问痕迹叠在一起，原本无法区分的查询开始有了差异。

研究使用Enron邮件、Apache Lucene邮件列表、Simple English Wikipedia，以及较新的Linux内核邮件列表、QEMU邮件列表和2026年1月新闻语料，共六组公开数据。

在0.1%已知明文下，Whisper的查询关键词正确恢复率为35.86%至49.01%；此前方法为17%至27%。已知明文提高到1%时，恢复率达到68.74%至95.12%，多数数据集超过80%。研究还测试了填充和隐藏容量等代表性防御，攻击仍然有效。

但这不是某个云盘或邮件服务已经被攻破。作者明确说明，实验全部在本地公开数据集上完成，没有攻击线上SSE服务，也没有指认厂商漏洞。测试还假设数据库和关键词集合保持静态；真实系统持续新增、删除文档时，攻击需要额外模型才能追踪变化。

指标也只是“正确猜回关键词的比例”，不是读出了同等比例的完整正文。论文讨论的是SSE泄露模型的结构性边界，不是一个可以给具体产品打补丁的零日缺陷。

加密把正文变成密文，却不会自动把“搜了什么、命中了谁、结果有多少”一起藏起来。AI降低的是利用这些旁路信息的门槛。

USENIX的会议页面把这项工作放在8月14日的密码学应用场次。它给企业的检查项也很直接：如果加密搜索方案仍向服务器暴露稳定的访问和容量模式，就不能再把“只泄露不到1%明文”当作足够保守的威胁假设。

更强的保护需要隐藏或扰动高阶共现关系，代价往往是更多计算、通信或查询延迟。正文是否加密只是第一问；搜索时留下多少可关联的脚印，才决定攻击者能把多少内容猜回来。

Mingyu Bian等，《Your Keywords Know Each Other: Breaking SSE with <1% Leaked Documents》，2026-08，https://www.usenix.org/system/files/usenixsecurity26-bian-mingyu.pdf
USENIX Association，《Your Keywords Know Each Other: Breaking SSE with <1% Leaked Documents》，2026-08，https://www.usenix.org/conference/usenixsecurity26/presentation/bian-mingyu
USENIX Association，《USENIX Security '26 Technical Sessions》，2026-08-12至14，https://www.usenix.org/conference/usenixsecurity26/technical-sessions