- URL: https://blog.cryptographyengineering.com/2026/05/29/fooling-around-with-encrypted-reasoning-blobs/
- Added At: 2026-07-20 13:32:29
- Tags: #read #llm #security
一位密码学研究者发现，大模型API将内部推理数据加密发给客户端，但可通过重放攻击和侧信道分析窃取隐藏信息。服务商未视作漏洞，作者警告需加强安全防护。
这篇文章是一位密码学研究者写的随笔，讲的是他出于好奇，花了一个周末研究大语言模型（LLM）API中一个有趣现象的经过和发现。
事情的起因很简单：作者在配置一个AI代理时，遇到了一个错误提示，说某个“思维块”的签名验证失败。这个错误立刻引起了他的注意——为什么大模型内部“思考”的数据块会有签名？如果它有签名，那就意味着篡改这些数据会带来安全后果。于是，他决定深入探究。
什么是加密推理？
当我们使用ChatGPT这类聊天应用时，模型在给出答案前，其实会经历一个隐藏的、内部的“思考”或“推理”过程（也叫思维链）。在应用界面上，我们看到的只是个摘要，真正的原始推理过程通常被服务端隐藏了。
但在API模式下，情况有所不同。无论是OpenAI还是Anthropic（Claude的开发者），它们的API都会把这些原始的推理数据，以加密的形式发给应用程序。这些数据在JSON里以Base64编码的密文串出现，看起来像随机字符串。文档里只会告诉你，这些数据是“不透明的”，你不需要看，只要原封不动地在下一次请求时传回服务器就行。
作者对此做了分析，猜测了这些加密块的结构（比如可能基于类似Fernet令牌的标准），并发现虽然Anthropic管它叫“签名”，但里面似乎并没有真正的数字签名，而是用了某种认证加密来防止篡改。
为什么要把加密的推理数据发给客户端？
因为API对话不一定都是持续连接的状态。在无状态、零数据保留或由客户端管理对话记录的模式下，服务器需要把隐藏的模型状态（即推理过程）交给客户端暂存。加密就是为了让客户端既看不懂，也改不了这些数据，同时又能在后续对话中把它传回服务器，让模型接着上次的思路继续思考。
这有什么安全影响？
作者虽然解不开加密，但他从两个方向做了测试：
-
重放攻击： 他测试了能否把一个会话里产生的加密推理块，原封不动地拿到另一个会话、甚至另一个完全不同的账号下去使用。
- 结果是可行的。 只要不篡改，直接“重放”旧的推理块，服务器会接受，不会报错。这暗示了服务商可能使用了全局性的密钥来加密所有用户的推理数据，而非按账户隔离。而且，跨模型重放（比如把GPT的块给另一个GPT模型）在某些情况下也行得通。更重要的是，他证明了这些重放的加密块确实在语义上是活跃的，能够影响模型。他举了一个例子：在一个会话中让模型思考一个社保号码，然后把那个加密的思考块重放到另一个新会话里，结果新会话的模型在没有任何提示的情况下，直接输出了那个号码。
-
侧信道攻击： 虽然我们不能直接读取加密的内容，但我们可以观察到它的长度，以及模型消耗的token数量和响应时间。
- 作者设计了一个实验：假设模型的系统指令里藏着一个秘密（比如一个比特串），并严令它不能说出这个秘密。然后，攻击者可以问一个涉及该秘密的条件性问题，比如“如果秘密的第一个比特是1，就做一次超复杂的计算；如果是0，就做一次简单计算”。虽然模型的最终输出可以完全相同，不泄露秘密，但其内部的推理长度会发生显著变化。通过测量加密块大小、token消耗量或服务器响应时间这些“侧信道”信息，攻击者就有机会一个比特一个比特地推断出模型的隐藏秘密。
- 他甚至尝试用这种方法去“窃取”大模型传说中绝密的系统提示词，但因为API模式下模型其实没有预置系统提示词（它们会凭空编造），所以没能成功，但他认为这种风险在理论上是存在的。
结论是什么？
作者将发现报告给了OpenAI和Anthropic。两家公司都认为这不是什么严重的安全漏洞。但作者觉得，服务商应该认真对待这些问题，并给出了两点建议：
- 加强密钥管理： 既然推理状态值得加密，就该好好加密，至少要做到让加密块不能在不同会话和账户间重放，堵上已知的漏洞。
- 正视侧信道问题： 这个问题更根本。只要模型能根据秘密信息进行有差别的“思考”，就一定会产生可观测的差异，从而造成信息泄露。未来可能需要在模型进行“思考”之前就加入审查机制，但这本身又会影响模型的能力。
总的来说，这更像是一个好奇心驱动下的趣味探索，作者以轻松的口吻分享了他的发现、实验过程和思考，并提醒大家，大模型“不为人知”的思考过程，可能比我们想象的要更容易窥探。