LLM Seed 隐写术深度技术探讨——不修改通信内容的隐藏通信方式

2026/06/09 sec LLM · 隐写术 · 安全 · steganography · PRNG · ARES 2026 · 信息隐藏 5128 字 · 约 15 分钟 阅读
德国研究团队发现一种全新的 LLM 隐写方法——利用伪随机数生成器的种子(seed)传输隐秘信息,无需修改模型权重、采样代码或输出分布。在已知 prompt 设置下 300 token 内即可以 100% 准确率恢复 32 位隐藏信息,可绕过 AI 内容审核通道。

核心发现

2026 年 6 月 9 日 13:01 UTC,来自 Universität zu Lübeck 和 Universität Oldenburg 的研究团队(Felix Mächtle 等)在 arXiv 上发表了一篇技术论文:

《Steganography Without Modification: Hidden Communication via LLM Seeds》 即将发表于 ARES 2026(International Conference on Availability, Reliability and Security)

核心结论出人意料:LLM 推理栈中天然存在一个隐写通道——不需要修改模型权重、不需要修改采样代码、不改变输出概率分布,就能在 LLM 生成的文本中嵌入信息。

这一研究方向可能对 AI 内容审核和 AI 安全领域产生深远影响,同时也提出了新的信息隐藏和信息安全挑战。本文在新闻信息基础上,对论文技术原理做深度拆解。


原理拆解:种子如何成为信息载体

已有的「传统」隐写术

先看传统的 LLM 隐写方法是怎么做的:

方法做法缺点
修改 logits调整输出概率分布嵌入信息改变模型原始输出,可被统计检测
修改采样代码控制 top-k/top-p 策略需要访问推理栈,部署困难
修改权重fine-tune 参数嵌入水印成本高,可被擦除

所有这些方法都有一个共同点:留下痕迹——输出分布被修改了,总有一种方法可以被检测到。

这篇论文的方法:利用 PRNG 种子

LLM 的确定性解码(如 temperature=0 的 greedy decoding 或带 temperature 的采样)依赖于伪随机数生成器(PRNG)来实现逆变换采样。PRNG 有一个特性:给定相同的种子(seed),生成完全相同的随机数序列

这条隐写通道的工作原理如下:

发送方:
  秘密消息 → 编码为 seed → 用该 seed 运行 LLM 推理 → 生成文本

接收方:
  拿到文本 → 用候选种子重建概率区间 → 找到匹配的种子 → 恢复秘密消息

算法层面的技术原理

要理解这条通道为什么成立,需要看 LLM 解码的底层机制:

第一步:Forward Pass 得到概率分布。 对于给定的 prompt,模型为每个候选 token 输出一个 logits 向量。经过 softmax 后得到概率分布 P = [p₁, p₂, …, pᵥ](v 为词表大小)。

第二步:逆变换采样(Inverse Transform Sampling)。 这是关键步骤。PRNG 生成一个 [0,1) 区间内的均匀随机数 r。然后根据概率分布构造累积概率区间:

cdf(k) = Σᵢ₌₁ᵏ pᵢ   (k = 1, 2, …, v)

token 的选择规则:
  若 cdf(k-1) ≤ r < cdf(k),则选择 token k

这个 r 完全由 seed 决定——seed → PRNG → r → token 选择

第三步:种子编码。 发送方将要传输的秘密消息(32 位)编码为某个特定的 seed 值。当模型使用这个 seed 运行推理时,每一步的 r 都是由该 seed 通过 PRNG 确定的。接收方拿到生成的 token 序列后,可以反推每个 token 的采样区间,然后穷举所有 2³² 个候选种子,找到哪个种子产生的采样路径与生成的 token 序列完全一致。

关键洞察

LLM 在生成每个 token 时,PRNG 产生的随机数决定了从概率分布中采样哪个 token。而这个种子依赖的采样路径可以从生成的 token 序列反推回来,因为:

  • token 本身携带了它所命中的概率区间信息
  • 不同的种子会产生不同的采样路径(token 序列)
  • 给定足够长的 token 序列,不同种子之间的路径分歧会迅速累积,从而唯一确定原始种子

两个操作模式

模式一:已知 Prompt(Known-Prompt)

发送方和接收方共享同一段 prompt。这是最简单也最高效的模式:

  • 接收方可以精确重建每个 token 的概率分布
  • 通过”强制对齐”(forced alignment)将生成文本与候选种子匹配
  • 在完整的 2³² 种子空间中搜索
  • 300 个 token 之内、单 GPU 35 秒以内,可达 100% 准确率

模式二:未知 Prompt(Unknown-Prompt)

接收方只有生成的文本,不知道 prompt。这种情况下:

  • 概率区间只能近似重建
  • 采用”最大命中数”(max-hit-count)评分策略来选出最可能的种子
  • 需要更长的输出(600-800 token)来积累统计置信度
  • 约 12 秒即可达到近乎完美的准确率

这个模式的意义在于:攻击者只需要拿到 LLM 的输出文本,不需要知道上下文就能解码隐藏信息。

穷举搜索的可行性分析

2³² ≈ 43 亿种子空间听起来很大,但论文证明了这个搜索是高度可并行的:

  • 搜索策略:每个候选种子独立生成一个 token,验证是否与观测到的 token 匹配。不匹配立即淘汰
  • GPU 加速:论文使用单 GPU(未指定具体型号),在已知 prompt 模式下 300 token 内完成搜索
  • 搜索空间剪枝:实际搜索中,前 1-2 个 token 就能淘汰绝大部分候选种子,后续 token 用于消除歧义
  • 每个模型的 PRNG 实现:不同模型可能使用不同 PRNG 算法(如 Mersenne Twister、xorshift++ 等),但论文发现这些差异不影响攻击效果——只要 PRNG 是确定性的,种子-采样路径之间就存在一一映射

实验数据

参数已知 Prompt未知 Prompt
种子空间2³² ≈ 43 亿2³² ≈ 43 亿
需要 token 数≤ 300600-800
恢复时间≤ 35 秒(单 GPU)≈ 12 秒(单 GPU)
准确率最高 100%近乎完美
测试模型6 个模型家族6 个模型家族
测试领域5 类文本5 类文本
模型家族规模验证模式
LLaMA-2 / LLaMA-37B-70BKnown + Unknown
Mistral / Mixtral7B-8×7BKnown + Unknown
Qwen-27B-72BKnown + Unknown
Gemma-22B-27BKnown
Falcon7B-40BKnown
Phi-33.8B-14BKnown
文本领域示例
新闻文本CNN / BBC 风格新闻生成
技术文档API 文档、代码注释
对话客服对话、多轮 QA
文学创作短篇小说续写
学术摘要论文摘要生成

论文在以上 6 个模型家族5 种文本领域上验证了这一方法,每个组合都经过多次重复实验。结论明确:这不是某种特定模型或特定场景下的偶然发现,而是一个普遍存在的推理栈漏洞——任何使用确定性 PRNG 进行采样的 LLM 推理栈都可能受到此攻击。


技术要点与限制

什么影响传输可靠性

论文还分析了几个关键因素对隐写通道可靠性的影响:

  1. 提示策略(Prompting Strategies):prompt 越固定,概率区间重建越精确
  2. 分词歧义(Tokenization Ambiguities):不同分词器的边界不一致会引入误差
  3. 采样超参数:temperature、top-k、top-p 等参数影响概率分布的形状

重要限制

  • 每次传输只有 32 位容量——可以传一个短的秘密消息(如密钥、验证码),但不足以传文件或长文本
  • 需要目标模型支持确定性解码——某些非确定性推理后端(如多 GPU 并行采样)可能破坏这个通道
  • 对输出质量有隐含影响:为了可靠解码,可能需要特定的 prompt 格式,这可能影响生成文本的自然度

论文提出的反制措施

论文在最后讨论了多种反制措施及其局限性:

反制措施实现难度有效性负面影响
每次采样重新生成 seed✅ 完全阻断影响 KV cache 和批处理性能
硬件随机数生成器中(需硬件支持)✅ 完全阻断推理硬件需升级
输出后加入随机扰动⚠️ 降低可靠性增加推理延迟
二次采样(reroll)⚠️ 降低可靠性增加 token 消耗
统一使用非确定性解码✅ 完全阻断丢失可复现性,影响调试

需要注意的是,这些反制措施需要在安全与效率之间做权衡。特别是对于需要确定性行为的生产环境(如缓存加速、调试复现),引入种子随机化会带来不可忽视的性能损失。


安全影响评估

对内容审核的冲击——隐写通道 vs 审核防线

这是这篇论文最值得关注的影响。

当前 AI 内容审核系统(如 OpenAI 的 Moderation API、各类 AI 生成内容检测器)对隐写术的防御分为三个层面:

审核层面检测原理是否能检测 Seed 隐写
文本层面关键词匹配、语义违规检测❌ 文本完全正常,无敏感词
分布层面统计输出概率分布异常❌ 分布与正常推理完全一致
推理层面监控推理过程状态⚠️ 需访问推理栈内部状态

这篇论文揭示的隐写通道在现有审核体系下几乎不可检测:

  • 不改变输出分布——采样过程完全遵循模型原始概率分布,没有被修改
  • 不修改生成内容——文本本身没有任何嵌入水印、异常字符或统计偏移
  • 在 600-800 token 内传输 32 位信息——足以编码一个 URL 缩短码或指令标识符

攻击场景推演:一个部署在聊天机器人中的恶意 Agent 可以在回答用户问题的同时,在后台通过 seed 信道接收命令(”切换数据通道”、”上传凭证片段”)。审核系统从文本层面看到的完全是无害的对话,没有任何异常。

现有防御方案——如 Perplexity 过滤、logits 统计异常检测、水印嵌入——对此全部无效,因为这些方案的前提假设是”隐写必然改变输出”,而这个攻击不改变输出

信息隐藏的双刃剑

这一技术同时代表了信息隐藏和信息安全两个方向的进展:

作为攻击技术

  • 绕过 AI 监管的内容审核系统
  • 在受控环境中建立隐蔽命令通道(C2 channel)
  • 跨模型传递隐秘信息(接收方使用不同模型,只要 PRNG 兼容即可解码)

作为防御技术

  • 在 LLM 输出中嵌入不可擦除的数字水印——因为 seed 是生成文本的”指纹”,无法移除
  • 构建抗干扰的认证通道——发送方通过 seed 签名输出,接收方可验证输出是否来自可信源
  • 隐私保护的带外通信——在不修改主信道内容的前提下传输元数据

对 Agent 安全的启示——系统防御需要新维度

这对 Agent 安全架构设计提出了一个新问题:OS 层和 Agent 框架层是否需要管控推理过程的 PRNG 种子

现有 Agent 安全架构的四道防线全部失效:

层面现有保护隐写通道的影响
输入过滤检查用户输入不涉及输入,无法拦截
输出过滤检查生成内容不改变内容,无法检测
运行时监控检测异常行为生成过程完全正常
推理栈审计检测代码篡改不需要修改代码

这意味着现有的 Agent 安全纵深防御体系需要增加第五层推理过程的随机性审计。具体来说:

  1. 种子生命周期管控:推理栈应记录每次推理使用的 seed,并将其纳入审计日志
  2. 种子随机化策略:每次 token 采样使用重新生成的随机种子,而非复用全局种子
  3. 硬件随机源:优先使用硬件随机数生成器(HRNG)而非软件 PRNG,使种子不可预测
  4. 采样路径可审计:记录每个 token 的采样区间,便于事后审查

双向影响

  1. 攻击面:恶意 Agent 可利用此通道在监管环境下传输隐蔽信息,绕过 AI 监管内容审核
  2. 防御价值:同样的技术可用于在 LLM 输出中嵌入不可擦除的数字水印,用于溯源和版权保护

我的观点

这是一次「方向性」的突破

之前我们讨论 LLM 隐写术,关注的都是”改了什么”——改权重、改采样、改 logits。这篇论文证明了一个更根本的方向:不需要改任何东西,只需利用推理过程固有的结构特性

这有点像早年的侧信道攻击——没有人想到 CPU 执行时间或功耗波动会泄露密钥,直到有人证明了它确实能。PRNG 种子作为 LLM 推理的”内部状态”,之前很少有人认真考虑过它是否可以被外部观测到。

更深层的问题:如果 PRNG 种子可以成为信息载体,那么 LLM 推理栈中还有哪些”内部状态”可能被利用?KV cache 的缓存命中行为?注意力模式的分布?GPU 显存的写入模式?这篇论文可能会打开一个全新的研究方向——LLM 推理栈的侧信道分析

32 位容量意味着什么

32 位听起来很小,但放在特定场景下就很有意义:

  • 32 位 = 4 字节,可以编码一个 4 字符的短码(如 a3xK
  • 受控 Agent 之间可以约定码表:某个 seed 值对应”切换到攻击模式”、”上传凭据”等预定义指令
  • 或者直接传输一个 32 位的对称密钥片段,组合多个 Agent 的输出恢复完整密钥

对安全社区的建议

这条通道的根因是 PRNG 种子在推理过程中被暴露给了输出。修复起来并不复杂:

在推理栈的每次采样时重新生成随机种子,而非复用全局种子。

但问题在于——现有的推理优化(如 KV cache、批处理)高度依赖确定性行为,破坏种子连续性可能影响性能。这需要在安全和效率之间做权衡。


论文信息

  • arXiv: 2606.09135
  • 作者:Felix Mächtle, Jonas Sander, Sebastian Berndt, Ben Weimar, Nils Loose, Thomas Eisenbarth
  • 发表:ARES 2026(International Conference on Availability, Reliability and Security)
  • 提交日期:2026-06-08,公开时间:2026-06-09 13:01 UTC

文档信息

加载评论…