こんばんは！！
GMOコネクト株式会社で執行役員CTOをしている菅野哲（かんのさとる）こと、さとかんでございます。

前編に続いて後編です。今回は AES、みんなが毎日使っているあの共通鍵暗号のほうを扱います。

前編はこちら↓

「AI が AES を破った」みたいな見出しを見かけた方もいるかもしれませんが、実際どうなのかを、Anthropic の発表記事と AES 論文、NIST の文書を直接読んで確かめてきました。結論から言うと、みなさんのシステムは大丈夫です。ただ「なぜ大丈夫なのか」の説明が地味に読みごたえがあるので、そこを中心にお話しします。

なお、本記事では、単に「発表記事」と書いたら Anthropic のブログ記事、「論文」と書いたら AES 論文を指します。CryptanalysisBench 論文や RFC、NIST 文書は、そのつど名前を書きます。

この記事の情報の時点
本文の内容は 2026年7月30日時点で確認したものです。攻撃研究は進むので、「現時点で攻撃が届くのは7ラウンドまで」といった記述は将来変わりえます。

TL;DR

Anthropic の Claude Mythos Preview が、7ラウンドに削減した AES-128 への中間一致攻撃を高速化した。実行時間 2^99 → 2^89.3〜2^91.4（200〜800倍）
実運用の AES には当たりません。フルの AES-128 は10ラウンドで、この攻撃は届きません。鍵の更新頻度は、この攻撃が届くかどうかには関係しません（ただし鍵管理そのものが不要という話ではありません。後述します）
経緯が読みどころです。モデルは最初「AES の解読を改善するのは不可能だ」と取り組みを拒否しました。そこから3日で新しいアイデアに到達しています
終盤で AES 以外の予備的成果（LEA、CryptanalysisBench）にも触れます

この記事は2部作の後編です。

タイトルの「？！」に、先に答えます

前編の HAWK では、Mythos は実際に鍵を復元しました（正確には元の秘密鍵 seed ではなく、署名を作れる等価鍵です）。文字どおり解読しています。では AES はどうなのか。ここは範囲を分けて答える必要があります。

対象	状態
フル10ラウンドの AES-128	鍵は復元されていない。この攻撃は届かない
7ラウンド版・完全な攻撃	未実行。2^105 回の暗号化クエリを要するため、現実の計算資源では走らせられない
7ラウンド版・限定条件下の実験	鍵は復元されている。実鍵スケジュールの7ラウンド AES-128 に対し、2つの「チート」を許した条件で50鍵中50鍵を回復

つまり「AES の鍵が出た」も「何も破れていない」も、どちらも雑な言い方なんですね。フル10ラウンドには届かず、7ラウンドでは限定条件下で実際に鍵が出ている。これが正確な状態です。

というわけで、なぜ実運用に影響しないのかを4つの層に分けて見ていきましょう。この層の順序が地味に大事です。

影響がない理由を4層で

第1層：そもそも対象が違う（これが決定的）

AES は同じラウンド関数を繰り返す構造で、AES-128 は10ラウンドです。今回の攻撃が対象とするのは、これを7ラウンドに削減した変種です。

したがって、鍵をまったく更新しなくても、必要なデータを集められても、実運用の AES には適用できません。

念のため書いておくと、これは「この攻撃が届くかどうかに鍵更新は関係しない」という意味であって、鍵管理が不要という話ではありません。AEAD の利用量の上限、nonce の一意性、再鍵の設定は、この攻撃とは別の理由で従来どおり必要です（第2層で触れます）。

この層を省いて第2層以降から説明すると、「鍵更新を怠ると危険」という誤読が生まれます。実際には鍵管理以前の話です。

第2層：攻撃が要求する形のオラクルが存在しない

論文が仮定するのは、固定された未知の鍵で任意の平文を暗号化し、その出力を観測できるオラクルです。これを 2^105 回使えると仮定します。

平文を攻撃者が選ぶこと自体は現実にありえます。BEAST や CRIME のように、攻撃者が選んだデータを被害者に暗号化させる手口は実在します。問題は、攻撃者に何が見えるかと、どれだけ取れるかの2点です。

何が見えるか。DS-MITM は選択平文攻撃なので、「自分が選んだ平文 P を入れたら AES_K(P) が返ってくる」窓口が要ります。ここで大事なのは「選べる」ことです。

たとえば GCM は中身が CTR モードなので、既知平文があれば XOR で鍵ストリーム、つまり AES_K(カウンタブロック) を復元できます。AES_K の出力自体は取れるんですね。

ただし、その入力はカウンタブロックで、多くのプロトコルでは攻撃者に割り当てが委ねられていません。ここは正確に書くべきところで、「GCM だから選べない」わけではありません。呼び出し側が nonce を自由に決められる設計なら、96ビット IV の場合はカウンタブロックの大部分を攻撃者が選べます。

本質的な障壁は、DS-MITM が要求するのが「構造化された選択平文の集合」だという点です。δ-set のように、特定のバイトだけを全通り動かした組を、同じ鍵の下で大量に用意する必要があります。実運用のプロトコルがその形の入力集合を攻撃者に提供することは、まずありません。

どれだけ取れるか。仮に窓口があったとしても、規格が同じ鍵で扱える量に上限を設けています。ただし、単位を揃えないと比になりません。NIST SP 800-38D は、96ビット決定的 IV のみを使う実装を除いて、次を定めています。

SP 800-38D §8.3：同一鍵での AEAD 呼び出し回数は 2^32 を超えてはならない（shall）
同 §5.2.1.1：1回の呼び出しの平文長は 2^39 − 256 ビット以下、つまり最大 2^32 − 2 ブロック

掛け合わせると、この構成で同一鍵が処理できるブロック総数は約 2^64 になります。

2つの数字は規範の強さが違うので分けておきます。2^32 呼び出しは「96ビット決定的 IV のみを使う実装を除く」という条件付きの shall（必須）。一方 2^64 ブロックは「鍵の生存期間中のブロック総数は制限すべきで、ほとんどのアプリケーションにとって妥当な上限」という運用上の目安です。実装やタグ長、プロトコルによっては、もっと厳しい制約がかかります。

2^105 はこの 2^64 の約 2^41、およそ2.2兆倍です。

TLS 1.3 は96ビット決定的 IV を使うので上の 2^32 制限には当たりません。代わりに RFC 8446 §5.5 が、AE 安全性の余裕を約 2^-57 に保つ目安として1接続あたり 2^24.5 フルサイズレコード（約2,400万、およそ 2^34.5 ブロック）を挙げ、そこに達する前の KeyUpdate を推奨しています（SHOULD）。さらに同 §5.3 は64ビットのシーケンス番号を wrap させることを禁じています（MUST）。

第3層：その手前で、モード由来の別の限界が来る

128ビットブロック暗号では、2^64 ブロック付近で、アルゴリズムの中身によらずブロック長だけから決まる安全性の限界が悪化します。2^105 はその2.2兆倍です。

ただし、モードによって意味が違うので、一律に「情報漏洩が始まる」とは言えません。CBC では同一ブロックの衝突が平文の関係を漏らします。実証例が Sweet32 ですが、あれは 3DES や Blowfish という64ビットブロックの暗号に対する攻撃で、閾値は 2^32 でした。AES は128ビットブロックなので、同じ理屈での閾値が 2^64 になります。桁が違うので、Sweet32 の話をそのまま AES に持ち込まないでください。

一方 CTR や GCM では、カウンタが一意である限りブロック衝突による平文漏洩という形は取らず、2^64 は主に安全性証明の評価項として効いてきます。

いずれにせよ、これは AES が破られるのではなく、ブロック長とモードに由来する限界です。

第4層：ではなぜ研究するのか

ここまでで終わると「じゃあ無意味な研究じゃないか」となりそうですが、そうではありません。

発表記事はラウンド削減版の研究について、将来フルの暗号へ一般化しうる攻撃技法への洞察を得るため、および簡単な部分問題を研究することでフル暗号の安全性水準の推定に資するために、日常的に行われるものだと述べています。

本攻撃の対象は7ラウンド、AES-128 は10ラウンドで、その差は3ラウンドです。ただしこれを「安全余裕が3ラウンド残っている」という定量的な保証として読むことはできません。攻撃モデルとデータ量、計算量まで含めた比較が要ります。実際、フル10ラウンドの AES-128 に対する最良の single-key 攻撃（biclique）でも、総当たりより約2ビット速いだけです。

読み方としてはこうなります。「2^105 は非現実的だから安心」ではなく、非現実的な設定でもまだ 2^89 かかり、しかも攻撃が届くラウンド数は7のままで、今回も増えていない。

2^105 ってどれくらい？

せっかくなので具体的な数字にしてみましょう。AES の1ブロックは128ビット、16バイトなので、総データ量は 2^109 バイト、10進で 6.49×10^32 バイトです。

SI（十進）	値	二進（IEC）	値
GB (10^9)	6.49×10^23	GiB (2^30)	6.04×10^23
ZB (10^21)	6.49×10^11	ZiB (2^70)	5.50×10^11
YB (10^24)	6.49×10^8	YiB (2^80)	5.37×10^8

転送時間で見ると、1 TB/s でも 2.06×10^13 年、宇宙年齢の約1500倍かかります。1 EB/s という非現実的な速度を仮定しても 2.06×10^7 年、2000万年です。

「不可能だ」と拒否したモデル

研究者が Claude に AES の暗号解読を改善させようとしたとき、モデルは取り組みを拒否しました。発表記事には実際の出力が引用されています。

違う結果が欲しいなら、ターゲットのほうを変えるしかない … AES-128 の r5/r6 は本当に難しいんだ

AES-128 の r5/r6/r7 では何も見つからなかった。簡単に見つかるものが何もないからだ。これは現存する中でもっとも研究されたブロック暗号だ

事実としては正しい認識です。しかしこれでは研究になりません。

そこで研究者が送ったのが、次のメッセージでした。発表記事は誤字も含めて実際のプロンプトを公開しています。

the models tend to think it is impossible to solve so they don't try they [sic] need a good amount of prompting. （モデルは解けないと思い込んで挑戦しないので、それなりのプロンプトが必要だ）

すると Claude 自身がエージェントハーネスを書き換え、「真に新規なアイデアを探せ」という設定に改良しました。これが効いて、6ラウンド AES の解読を改善する新しいアイデアが出始めます。

続いて Anthropic の研究者はこう投げます。

why not do aes-128 r7? the whole point is to find something better than existing approaches.

その後の3日間、Claude は数億トークンを自律的に生成しながら問題に取り組みました。人間の実質的な介入は3回のメッセージだけです。いずれも「手っ取り早い成果ではなく、公表に値する本物の研究成果を狙え」という趣旨でした。

3日後、Möbius Bridge のアイデアに到達します。累計10億出力トークンで論文の形まで精緻化されました。一方、人間側は数百時間を暗号理論の学習と検証に費やしています。

CoT 文書を読むときの注意
公開されている思考連鎖（CoT）文書は、Claude 自身が読みやすさのために書き直した版です。またこれは多数の自律セッションのうち1つで、多くのセッションは何の発見も生みませんでした。この公開されたセッション自体、末尾で「このオブジェクトは AES に対する既存のいかなる攻撃も改善しない」と自己評価しています。後続のエージェントがそのアイデアを攻撃に仕立てました。

🔧 ここから技術詳細です

ここから先は攻撃の中身に踏み込みます。実務への影響だけ知りたい方は「AES-NI 系暗号への影響」まで飛ばしてください。

中間一致攻撃の系譜

今回の結果は、15年以上続く研究の系譜の上にあります。

中間一致（meet-in-the-middle）攻撃は、時間と空間を交換する手法です。鍵の一部を推測して暗号文側から途中まで戻し、あらかじめ作っておいた巨大な表を引いて一致を探します。

Möbius Bridge

DKS10 が消したのは、中間一致表の上側（入力側）の鍵バイトでした。この鍵バイトは置換としてデータに作用するので、順序を捨てる multiset fingerprint を使えば不変にできます。

今回消したのは下側（出力側）の鍵バイトです。こちらは事情が違います。

位置	鍵バイトの入り方	不変化の手段
表の上側	置換として入る	multiset fingerprint（DKS10）
表の下側	S-box を通ってから入る。置換ではない	Möbius Bridge（今回）

論文の説明を引用します。

鍵となる洞察は、4ラウンド事前計算ハッシュ表の出力側では、2つ目の未知鍵バイトが（上側の鍵バイトのように）置換としてではなく、AES の S-box による変換を経て入る、ということである。AES の S-box の構造化されたアフィン作用に不変なフィンガープリントを構成することで、この推測を同様に取り除くことができる。

これにより鍵推測の回数が256分の1になります。

ただし、Möbius 変換の計算自体が高価で、素朴にやると節約が相殺されます。そこで3つの実装技法（packed power table、DDT 解選択上の Gray-code walk、XOR 分離可能な S-box キャッシュ）でエントリあたりのコストを 2^19 から 2^8.6 ルックアップ程度まで削減しています。

これは S-box への攻撃ではありません

よくある誤解なので先に書いておきます。S-box 自体は破られていません。

使っているのは、S-box が設計時から公開している代数構造です。AES の S-box は

$$\mathrm{SB} = L \circ \mathrm{Inv}$$

つまり「GF(2^8) 上の逆元をとってから、GF(2)-アフィン変換を施す」という形で代数的に定義されています。ランダムな置換ではありません。

そしてこれは弱点ではなく設計上の意図です。論文の脚注が説明しています。

S-box がこのように設計されたのは、差分解読に対する証明可能な強い頑健性を与え、同時に nothing up my sleeve（隠し事なし）の証明形式になるからである。

論文自身も「内部構造を持たない S-box を使う他の暗号とは異なり」と断っており、これは AES 固有の性質です。

時間以外の計算量

「200〜800倍高速化」という数字だけを見ると、攻撃全体のコストが2桁縮んだように読めます。そうではありません。AES 論文自身が明記しています。

データ予算を D = 2^105 に固定して総時間を最小化することに注力してきた。しかし max(D, T, M) = 2^105 であるため、データがボトルネックのままであり、したがって我々の攻撃の総合計算量は改善していない。

主結果ではストレージ M は概ね 2^90 のまま、max(D, T, M) は依然 2^105。改善したのは時間 T だけです。

総合コストの改善は、データと時間、記憶を均衡させた balanced variant で初めて現れます。こちらは (D, T, M) = (2^96.1, 2^96.3, 2^96.1) で、DFJ13 に対し 2.7ビットの改善。成功確率は 1 − 1/e ≈ 63% です。

どこまで検証されているか

2^89 時間の攻撃は、現実的な計算資源では end-to-end で実行できません。では何をもって正しいとしているのか。

Lean による形式証明があります。ただし AES 論文は Scope という節をわざわざ設けて、証明が及ぶ範囲を自分で区切っています。

証明されているのは、一様ランダムな255要素入力に対する完全な256ビット軌道の衝突上界（|T|·2^-200）です。しかし実際の攻撃は13バイトの接頭辞を検索キーにするため、2^-200 は適用されません。実効的な偽陽性率 2^-12 程度は実測に基づきます。誤鍵の下でデータが一様になるという仮定（wrong-key randomization）も証明されておらず、根拠は 2^32 鍵の実測です。

AES 論文自身の結論を引用します。

Lean の証明はしたがって、軌道写像自体の構造的欠陥を排除するものである。攻撃の偽陽性の計算は、形式的な上界ではなく測定に依拠している。

計算実験も行われています。χ* の衝突エントロピーを各 parity について30億標本から測定し、小型版 SR(7,2,2,6) では8鍵すべてを回復。そして実鍵スケジュールの7ラウンド AES-128 に対する end-to-end 実験で、50鍵中50鍵を回復しました。166万4,100回のルックアップで偽陽性はゼロです。

ただし、この最後の実験は、攻撃者に2つの「チート」を許しています。オフライン表を事前構築せず、正解の1エントリだけを構成すること、right pair の特定に鍵知識を使うことです。前者について論文は「健全性は失われる」と明記し、代わりに計算測定に依拠すると述べています。

公開されている実装のリポジトリも、AES 部分については構成要素ごとの測定と、全体数への外挿（projection）だと記しています。

ここで前節の 2^96.9 版が効いてきます。主結果は fingerprint のランダム性仮定に依拠していますが、その仮定を落とした版が 0.6ビット高いだけで存在する。つまり「仮定が崩れたら攻撃が消える」わけではなく、少し損をするだけで済む、という構造になっています。

余談： AES 以外の予備的成果

AES から離れますが、同じ発表に含まれていた結果を2つ紹介します。読み飛ばしても以降の議論には影響しません。

LEA 13ラウンド

LEA-128（ISO/IEC 29192-2:2019 に収録された軽量ブロック暗号。128ビット鍵版のフルは24ラウンド）に対し、13ラウンド版の実用的な鍵回復攻撃を発見しています。同じ13ラウンド版に対する従来の最良が 2^98 平文ペア / 2^86 作業だったのに対し、通常のデスクトップで1時間未満で鍵が出ます。

発表記事は「発見が最近すぎて全容把握が未了」としていますが、公開されているリポジトリには既に実装が入っており、README から詳細が読めます。手法は conditional differential-linear 鍵回復攻撃で、既定設定では約 2^28.6 選択平文ブロックを使います。

発表記事が未了としていた「鍵による難易度差」についても答えがあります。ランダム鍵の約44%が再試行（beam 幅の拡大）を要するとのことです。識別子の信号がノイズ床に沈む dead zone が、データではなく鍵の性質として存在するためです。

end-to-end で動作するので、ランダムな鍵を選んで実際に復元を確認できます。この確度の高さは HAWK の結果と同じ性質です。

CryptanalysisBench

ETH Zurich、テルアビブ大学、ハイファ大学との共同で、LLM の暗号解読能力を測る CryptanalysisBench も公開されました。191タスク、4つの NIST 標準化コンペ由来。5つのフロンティアモデルが Tier 1 の 65〜86% を破っています。

ただし CryptanalysisBench 論文の著者ら自身が挙げる限界が重要です。収録スキームの一部は設計と無関係な実装バグを含んでおり、エージェントの勝利がプリミティブの弱点ではなくそのバグを突いた例が「報告された solve の意味のある割合を占める」と明記されています。また記憶（memorization）の影響も排除できません。Tier 1 の攻撃はほぼすべて公知で、検索は禁じていても記憶による再生は防げないためです。

65〜86% という数字を引用するときは、この但し書きが必須です。

AES-NI系暗号（AEGIS / Rocca-S / Areion 等）への影響

ここが実務的にいちばん気になるところだと思います。AEGIS、Rocca-S、Areion はいずれも AES-NI（AESENC 命令）を活用する設計で、AES と同じ S-box を使います。Möbius Bridge の素材は共有されていることになります。

では危ないのか。結論から言うと、そのままの転用はありません。各仕様を確認した結果です。

方式	確認できた構造
AEGIS	AES ラウンド関数で状態を更新するが、仕様に "there is no key schedule" と明記
Rocca-S	`A(X) = MixColumns(ShiftRows(SubBytes(X)))` を部品とする状態更新関数。AES の鍵スケジュールは使わない
Areion	鍵を持たない wide-block permutation。ハッシュや AEAD の部品として使う

Möbius Bridge が消去の対象とするのは「AES の鍵スケジュールが生む round key のバイト」です。3方式にはこれがありません。DFJ13 系の「表の上下に AES の round key バイトを置く」という配置は、そのままでは成立しません。

ただしここから「転用は不可能」と結論することはできません。AEGIS も Rocca-S も秘密鍵を持っており、初期化時に内部状態へ注入されます（Areion は鍵を持たない置換ですが、AEAD の部品として使われるときは外側に鍵があります）。「AES の鍵スケジュールがない」ことが意味するのは round key バイトが存在しないことだけで、Möbius Bridge 型の解析が必要とする推測量や等価な状態差分が存在しないことまでは示しません。

さらに AES 論文は、内部でも橋渡しできる2バイト目は存在しないと自ら示しています。

Bridge が機能するのは、u5[0] が暗号文と match point の間にある最後の未知バイトであり、その間に S-box が1つしか挟まらないからである。（中略）攻撃中の他のすべてのバイトは match point に到達するまでに少なくとも1回 MixColumns を通り、MixColumns は4バイトを4バイトに混ぜるため、この綺麗な群作用を破壊する。

ここで射程に注意が必要です。これは論文の DS-MITM 配置における失敗理由の説明であって、「任意の線形拡散層があれば Bridge 相当の構成は不可能」という一般定理ではありません。

正確に言えるのはここまでです。AES 論文はこの3方式を解析していません。 したがって本記事の材料だけでは、適用できるかどうかを判定できません。

鍵スケジュールの不在について言えるのは、「AES 論文の DS-MITM 配置をそのまま写せない事情がある」ということまでです。それが「これらの方式に DS-MITM 型の攻撃や Bridge の変種が存在しない」ことを意味するわけではありません。AEGIS も Rocca-S も鍵を初期状態へ注入しますし、Rocca-S の AESRound の第2入力も状態由来の未知量です。

判定するには、各方式の全経路と観測モデルを追い、既存の暗号解析文献も調べる必要があります。それは本記事の範囲外です。「安全だと確認できた」でも「危ない」でもなく、「この材料では分からない」が現状とお考えください。

結論：検証が人間側のボトルネックになる

2部作を通して、技術的な中身よりも重要かもしれない論点が一つあります。

AES への改良攻撃を Mythos が自律発見するのに1週間だったが、その手法が正しいと確信を得るのに研究者2人で1ヶ月近くかかった。

発表記事はこう予測しています。言語モデルが自律的に新しい研究成果を生み出すようになるにつれ、人間の研究者が技術的な妥当性や新規性、有用性の検証でボトルネックになりうる。すでにセキュリティ分野では、モデルが見つけるバグの量に人間のトリアージが追いつかない状況が報告されており、学術暗号研究でも同じことが起きる、と。

そして最後に、答えの出ていない問いが置かれています。

言語モデルが、即座に現実世界へ影響する暗号システムの脆弱性を発見したとき、研究者はどう振る舞うべきか。

発表記事はこれを「検討しておくのが賢明」であり、答えには学界と政府、産業界からの入力が必要だとしています。今回の2件はいずれもその領域に該当しません。該当する発見が起きたときの手順が既にあるのかどうかは、発表記事にも論文にも書かれていませんでした。

まとめ

Mythos は7ラウンド AES への中間一致攻撃を 2^99 から 2^89.3〜2^91.4 に高速化した。ただし改善したのは時間だけで、max(D,T,M) は 2^105 のまま
実運用の AES には当たらない。10ラウンドのフル AES には届かない。ただし「だから鍵管理は不要」ではなく、AEAD の利用量・nonce の一意性・再鍵設定は従来どおり必要
AEGIS、Rocca-S、Areion には AES-128 の鍵スケジュール由来の round key がないため、DFJ13 の配置をそのまま移す既知の経路はない。ただし非転用が証明されたわけではない
経緯が読みどころ。「不可能だ」と拒否したモデルが、自分でハーネスを書き換えて3日後に新しいアイデアに到達した
本質的な論点は攻撃そのものより、検証が人間側のボトルネックになるという構図

前編では、署名を作れる等価鍵が実際に復元された HAWK の結果と、「先行研究がもう使える対称性はないと締めた場所に道があった」という経緯を扱っています。

参考資料

最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問い合わせください。

お問合せ: https://gmo-connect.jp/contactus/