DATA LEAK MEDIUM NEW

LLM 推理的侧信道攻击：即使有 TLS，你的提示词也会泄露

推测解码与流式响应会产生流量模式，泄露提示词的主题、语言、甚至个人信息——而且是通过加密连接。本文梳理三篇论文及其防御方法。

2026-06-17 // 6 min affects: chatgpt, claude, vllm, open-weight-llms

What is this?

侧信道攻击不读取你与 LLM 对话的内容——它读取对话的形状。模型回传的加密数据包的大小与时序，带有足够的结构来推断你在谈论什么，即便 TLS 隐藏了实际文本的每一个字节。2026 年 2 月 17 日，Bruce Schneier 汇总了三篇论文，让这一点变得具体；它们共同描述了一类与提示词注入和越狱无关的隐私泄露，且影响着大型供应商的生产环境服务。

贯穿其中的主线是：让现代 LLM 服务变快的优化手段——逐 token 流式输出、推测解码、并行解码——都依赖于数据。token 到达的速度以及每次网络 flush 发送多少个 token，取决于模型正在生成什么。这种依赖关系就是一个可测量的信号。我们报道它，是因为这是一类输入过滤和输出审核都无法解决的结构性隐私风险，也因为防御者很少把”一次聊天会话的网络踪迹”当作敏感数据。

How it works

三项已发表的成果勾勒出这一攻击面。它们都不需要破解加密。

Remote Timing Attacks on Efficient Language Model Inference（arXiv 2410.17175，2024 年 10 月发布）表明，推测采样和并行解码等技术会引入依赖数据的时序特征。通过被动监听用户与远程模型之间的加密流量，观察者能得知响应何时更快或更慢。在开源系统上，作者以超过 90% 的精度还原对话主题——例如医疗咨询与编程帮助之分；针对生产环境的 ChatGPT 和 Claude，他们能区分具体消息或推断用户语言；而主动攻击者借助一种 boosting 技术，可从开源部署中恢复电话号码或卡号等个人信息。

When Speculation Spills Secrets（arXiv 2411.01076，2024 年 11 月发布）专门分离出推测解码。由于该方案并行验证多个候选 token，每次迭代中被接受与被拒绝的 token 数量取决于输入，并体现在数据包大小上。在研究原型和生产级 vLLM 上测试，观察者能在 0.3 的温度下以超过 75% 的精度从一组 50 条提示词中识别查询——REST 100%、LADE 91.6%、BiLD 95.2%、EAGLE 77.6%——即便在温度 1.0 下也远高于 2% 的随机基线。同一信道还能以超过 25 token/秒的速率泄露用于预测的机密数据存储内容。

Whisper Leak（arXiv 2511.03675，2025 年 11 月发布）将流式场景推广到大型供应商的 28 个流行 LLM，根据数据包大小与时序对提示词主题进行分类，AUPRC 常常 >98%，在”洗钱”等敏感主题上即便噪声/目标比为 10000:1 也能达到 100% 的精度。作者进行了负责任的披露，并与供应商合作推出了初步对策。

What an eavesdropper sees           What it leaks
----------------------------------  -----------------------------------------
Inter-token arrival timing          Topic class, conversation language
Per-iteration token / packet count  Speculative accept/reject pattern → query
                                     fingerprint, datastore contents
Streaming packet size distribution  Topic classification across many models

Why it matters

这与大多数 LLM 攻击处于不同的威胁模型中。攻击者是任何能观察网络路径的人——ISP、进行监控的政府、同一 Wi-Fi 上的人，或被攻陷的上游路由器——而且他们完全不需要账号、恶意提示词或对模型的访问权限。这种泄露能在 TLS 下存活，因为它存在于元数据而非明文之中。对于将 LLM 用于医疗、法律、金融或其他机密事务的人来说，“我在谈论什么主题”本身就是敏感信息，而 98% AUPRC 的主题推断就是一次真实的泄露。数据存储提取的结果更糟：它仅凭时序就能从生产系统中拉出检索内容。这与我们在前缀缓存时序窃取提示词和推理泄露预算中报道过的更广泛的推理侧泄露问题相连——服务层，而不仅仅是模型，才是攻击面。

Defenses

这些论文提出并评估了具体的缓解措施。Whisper Leak 作者给出的诚实总结是：每种措施都有帮助，但没有一种能完全关闭该信道，因此要分层叠加使用。

填充数据包大小。 随机填充和固定大小缓冲会模糊用于识别查询的大小信号。它会消耗带宽；在敏感端点上为此预留资源。
在 flush 前批量并聚合 token。 按迭代聚合 token 和批处理可打破推测解码暴露出的”一个 token 一个数据包”关系。用少量可感知延迟换取大量信号削减。
注入掩护流量。 数据包注入会加入诱饵 flush，使可观察的数据流不再跟随生成过程。Whisper Leak 将其评估为一种部分控制手段。
把推测/并行解码当作一项隐私设置。 对高机密工作负载，可考虑禁用推测解码，或在隔离的本地部署中运行模型，从而在用户与模型之间不存在可观察的链路。
不要仅依赖 TLS 来保证机密性。 如果你的用户可能面对网络层面的攻击者，请说明提示词的主题可能泄露，并将敏感用途路由到带填充/批处理的端点或本地推理。

Status

这些是已发表且经过评审渠道的成果，并非零日漏洞；流式变体已进行负责任披露，供应商对策正在推进。请将上述缓解措施视为当前的最先进水平：它们能减少但无法消除 LLM 服务的元数据泄露。