# Let's talk about encrypted reasoning. Matthew Green (2026-05-29) > **Cikk:** *Let's talk about encrypted reasoning* • **Szerző:** Matthew Green (kriptográfus, Johns Hopkins University, a Cryptography Engineering blog társszerzője) • **Forrás:** • **Publikálva:** 2026-05-29 (frissítve: 2026-08-11 — európai kutatók valódi attack-ot csináltak a poszt ötletéből) • **Hossz:** 3268 szó --- ## A lényeg A Johns Hopkins-i kriptográfus Matthew Green 2026-05-29-én publikált „Let's talk about encrypted reasoning” című cikke az LLM-ek (OpenAI Responses, Anthropic Messages) rejtett reasoning csatornáját vizsgálja. A felfedezés: a modellek a chain-of-thought (CoT) reasoning trace-et **titkosítva küldik vissza a kliensnek**, és a kliensnek ezt a blob-ot kell visszaküldenie a következő turnusban. Green 20 óra munka és 5 millió Codex token után arra jut, hogy bár a blob-ok tartalma nem olvasható, a kriptográfia meglepően gyenge: **valószínűleg single global key** van, és a blob-ok **replayable-ek** session-ök, account-ok és modellek között is. A 2026-08-11-i frissítés megerősíti, hogy európai kutatók valódi, működő attack-ot építettek a poszt ötletéből. --- ## A cikk háttere és a felfedezés A cikk Green OpenClaw agent konfigurálásával indul, ahol a Claude Messages API-t használva egy szokatlan hibát kap: a modell „thinking” block-jában **signature** jelenik meg. A kriptográfusok számára ez a fajta hiba ellenállhatatlan: ha a thinking block-ok alá vannak írva, akkor a tampering-nek biztonsági implikációi kell legyenek — és Green hétvégéje elindul a lejtőn. A felfedezés lényege: az LLM provider-ek (OpenAI Responses, Anthropic Messages) a CoT reasoning-et JSON formátumban küldik vissza a kliensnek, és a kliens **köteles visszaküldeni** a blob-ot a következő turnusban. A blob egy base64-encoded string, ami valójában **authenticated ciphertext** (a 12-byte IV GCM-re vagy ChaCha-ra utal). A kliens nem olvashatja, de a provider visszafejti és felhasználja a beszélgetés folytatásához. Ez a mechanizmus a „stateless, zero-retention, tool-loop” üzemmódokhoz kell: ahol a szerver nem tárolja a beszélgetés állapotát, a kliens viszi tovább. ## Miért érdekes ez egyáltalán? Green a 2024-es OpenAI o1 bevezető posztját idézi, ami egy fontos utalást tett: a CoT reasoning **érzékeny információt** tartalmazhat, amit a modell egyébként nem osztana meg a felhasználóval. A blob-ok tehát potenciálisan a modell „belső monológját” rejtik — olyan dolgokat, amiket a modell „gondol”, de a végső válaszban nem mond ki. Ez teszi a blob-okat **rendkívül csábítóvá a támadók számára**. A nyilvánvaló védelmi réteg a kriptográfia: a blob-ok nem olvashatók, és bármilyen módosítás azonnali API hibát generál. Green első kétségei ezen a ponton kezdődnek, ha a védelem ennyire nyilvánvaló, mi értelme a globális aláírásnak, és vajon csakugyan erős-e? ## A két támadási vektor: replay és side channel Green két konkrét irányban vizsgálódik, és mindkettőben talál is fogást: ### 1. Replay attack A tampering (bármilyen bit módosítása) azonnali hibát generál, ez védett. Viszont a **változatlan replay** más kontextusban: - **Session-en belüli replay:** ugyanazon session korábbi blob-ját visszaküldeni, működik, nincs hiba - **Session-ök közötti replay:** másik session-ből származó blob-ot visszaküldeni, szintén működik - **Account-ok közötti replay:** OpenAI: másik accountból származó blob-ot visszaküldeni, működik; Anthropic Claude-ok itt „fussy”-k voltak - **Modellek közötti replay:** OpenAI-nál más modellből származó blob-ot visszaküldeni, működik A kriptográfiai implikáció egyértelmű: a provider-ek **valószínűleg single global key-t** használnak az összes blob-hoz, nem per-account key-t. Ez azt jelenti, hogy a zero-data retention módban mindenki reasoning data-ja ugyanazon (nem túl gyakran rotált) kulcs alatt van, nem per-account védelem alatt. A globális kulcs egy új fenyegetési modellt is felvet: ha egy alkalmazás chat interfészt exponál külső feleknek, a JSON-ba injektált blob-ok a modell viselkedését befolyásolhatják („sanitize your chat inputs!”). Ez a támadás kevésbé súlyos, mint a kriptográfiai törés, de a gyakorlatban fontos. ### 2. Side channel: hosszúság és időzítés A blob-ok tartalma nem olvasható, de a **hosszúságuk** igen. Ez a side channel önmagában is információ-szivárgás: a CoT hossza korrelál a modell „gondolkodási mélységével”, ami viszont korrelálhat a prompt tartalmával. A Codex kísérletek során Green meglepő felfedezést tett: a side channel **aktív**, bár a konkrét alkalmazhatóságot nem sikerült drámaian demonstrálnia. ## A „Mike” anekdota: amikor a modell tényleg „olvassa” a blob-ot A replay-ek túlnyomórészt csendben elnyelődnek a modell által, de Green egy fontos kivételt talált: GPT 5.5 **néha demonstrálja**, hogy valóban olvassa a blob-ot. Az egyik kísérletben az egyik session egy social security number-ről „gondolkodott”, és a másik session-be (másik account) replay-elt blob-bal a modell **kibocsátotta ugyanazt a számot prompt nélkül**. Green itt szúrja közbe a „Who the hell is Mike?” kérdést, az ilyen típusú szivárgás nem csak elméleti. Ez a kísérlet bizonyítja, hogy a blob-ok **„semantically active”**-ak, nem csak technikai szintű validáció történik. A modell valóban dekódolja és felhasználja a tartalmukat, ami a security implications-t drámaian felerősíti. ## A kutatás tanulságai és a 2026-08-11 update Green a cikkben hangsúlyozza, hogy ez **nem egy klasszikus sebezhetőség**, nincs azonnali exploit, nincs drámai adatszivárgás. A „disappointing project” jelzővel illeti a kutatást, mert bár talált valamit, nem tudta drámaian demonstrálni a támadás súlyosságát. A Codex kísérletek során az OpenAI cyber trusted access rendszere meg is akasztotta a kutatást (Green driver license-et volt kénytelen bemutatni, hogy tovább dolgozhasson). A 2026-08-11-i frissítésben Green bejelenti, hogy **európai kutatók valódi, működő attack-ot** építettek a poszt ötletéből. A linkelt paper és writeup megerősíti, hogy a globális kulcs és a replay-ability nem csak Green elméleti aggálya, hanem valódi, alkalmazható támadási vektor. ## A Green által javasolt lépések A cikk utolsó szakasza két szinten fogalmazza meg a teendőket: **Egyszerű lépések (a provider-ek részére):** - A key management javítása: ha a reasoning state titkosítása indokolt, akkor **rendes titkosítás**, a blob-ok ne legyenek session-ök és account-ok között replay-elhetők - A globális kulcs helyett per-account kulcs, gyakori rotációval - A 12-byte IV túl rövid, hosszabb, randomizált IV-k használata **Nehéz lépések (a side channel ellen):** - A side channel-ek eredendően kapcsolódnak a modell működéséhez: ha a modell „secret-dependent reasoning”-et végez, a szivárgás szinte elkerülhetetlen - A megoldás a **policy gate-ek** alkalmazása a reasoning előtt: a modell ne is gondolkodhasson érzékeny adatokról - A policy gate-ek alkalmazása viszont **maga is reasoning**-t igényel, ez egy rekurzív probléma, amire Green nem kínál megoldást A cikk utolsó sora önvallomás: „This stuff makes me grateful I'm just a cryptographer and I don't have to think about this sort of problem.” ## A cikk kontextusa és Henky-szempontú relevancia Ez a cikk a **LLM API security** kategóriába tartozik, és több szálon kapcsolódik a Henky által követett privacy/security vonalhoz: 1. **Privacy implications**, a reasoning blob-ok érzékeny információt hordozhatnak, és a globális kulcs miatt ez az információ kiszivároghat más session-ökbe 2. **Supply chain security**, a külső API-ra épülő alkalmazások sebezhetők a JSON injection-nel szemben a chat interfészeken 3. **Agent security**. Green OpenClaw agent konfigurálása közben fedezte fel a hibát; a coding agent-ek saját biztonsági felületet jelentenek 4. **Frontier LLM security**, a tag-ek között ez explicit: `frontier-llm-apis`, `coding-agents`, `Cryptography` A cikk a Cryptography Engineering blog egyik legérdekesebb 2026-os posztja, mert a „thinking blocks” aláírása egy **kriptográfiai implementation detail**, ami a gyakorlatban **privacy és security implications**-szel jár. A 2026-08-11-i frissítéssel együtt ez a poszt egy komplett esettanulmány arról, hogyan indul egy hétvégi hobbiprojekt valódi security research-cé. ## Összegzés A cikk legfontosabb megállapításai: - Az LLM provider-ek (OpenAI, Anthropic) a CoT reasoning-et **titkosítva küldik** a kliensnek, és a kliens viszi tovább a beszélgetés állapotát - A blob-ok **single global key**-vel vannak védve, nem per-account kulccsal → **replay-elhetők** session-ök, account-ok és (OpenAI esetén) modellek között - A blob-ok **hosszúsága** side channel-ként működik, bár a konkrét alkalmazás nem drámai - A 2026-08-11-i frissítés megerősíti, hogy európai kutatók valódi, működő attack-ot építettek az ötletből - A Green által javasolt javítások: per-account kulcs, gyakori rotáció, hosszabb IV, policy gate-ek a reasoning előtt A poszt értéke: a kriptográfusok klasszikus „scratch an itch” projektje, ami a frontier LLM API-k egy nem dokumentált belső mechanizmusát hozta felszínre — és a kutatói közösség ezt azonnal valódi attack research-cé fejlesztette. --- ## Forrás - **Eredeti cikk:** - **Szerző:** Matthew Green (kriptográfus, Johns Hopkins University, a Cryptography Engineering blog társszerzője; korábbi munkák: Zerocash, Signal Protocol, OpenSSL egyes sebezhetőségek) - **Publikálva:** 2026-05-29 • **Frissítve:** 2026-08-11 (európai kutatók valódi attack-ot csináltak) - **Cikk kulcsszavak:** encrypted reasoning, CoT (chain-of-thought), OpenAI Responses API, Anthropic Messages API, Claude, GPT 5.5, Codex, OpenClaw, thinking blocks, signature, authenticated ciphertext, GCM, ChaCha, IV, replay attack, side channel, zero-data retention, global key, per-account key, policy gate, semantic activation, „who the hell is Mike”, front-end LLM security, coding agents, supply chain - **Feldolgozás:** Henky-pipeline (`article_from_blog`, 2026-08-13) - **Forrásszöveg hossza:** 3268 szó (18847 karakter), < 5000 szó, ezért fő agent self-write, subagent dispatch nem kell