Crypto Protocol Diagram

以下のいずれかから、Mermaid sequenceDiagram（ファイルに出力）とASCIIシーケンス図（インラインで出力）を生成します：

• ソースコード — 暗号化プロトコルを実装したコード、または
• 仕様 — RFC、学術論文、疑似コード、通常の記述、ProVerif (.pv)、またはTamarin (.spthy) モデル。

使用するツール： Read、Write、Grep、Glob、Bash、WebFetch（URL仕様用）。

diagramming-codeスキル（コード構造を視覚化）とは異なり、このスキルはプロトコルセマンティクスを抽出します：誰が誰に何を送るのか、各ステップでどのような暗号化変換が発生するのか、どのようなプロトコルフェーズが存在するのか。

コールグラフ、クラス階層、またはモジュール依存関係マップの場合は、diagramming-codeスキルを使用してください。

使用する場面

• ユーザーが暗号化プロトコルを図解、視覚化、または抽出するよう要求している
• 入力がハンドシェイク、キー交換、または多者間プロトコルを実装したソースコード
• 入力がRFC、学術論文、疑似コード、または正式なモデル（ProVerif/Tamarin）
• ユーザーが特定のプロトコル（TLS、Noise、Signal、X3DH、FROST）を名前で指定している

使用しない場面

• ユーザーがコールグラフ、クラス階層、またはモジュール依存関係マップを希望している — diagramming-codeを使用
• ユーザーがプロトコルを正式に検証したいと考えている — 図を生成した後にmermaid-to-proverifを使用
• 入力に暗号化プロトコルセマンティクス（関係者なし、メッセージ交換なし）がない

却下する根拠

根拠	誤りの理由	必要なアクション
「プロトコルはシンプルなので、メモリから図解できる」	メモリベースの図解はステップを見落とし、矢印を逆にする	ソースまたは仕様を体系的に読む
「コードが存在するので、仕様パスをスキップします」	コードは仕様から逸脱する可能性があります — 両方のパスは異なるバグを検出します	両方が存在する場合は、仕様ワークフローを最初に実行し、コード逸脱をアノテートします
「暗号化アノテーションは装飾的なオプションです」	暗号化アノテーションなしでは、図はただのメッセージフロー — セキュリティレビューには役立たない	すべての暗号化操作をアノテートする
「中止パスは明白なので、altブロックは必要ありません」	暗黙的な中止処理は、エラーチェックの欠落を隠します	すべての中止/エラーパスをaltブロックで表示
「例をチェックする必要がありません」	例は予想される出力品質基準を定義します	なじみのない入力を処理する前に、関連する例を研究する
「ProVerif/Tamarinモデルはコード、仕様ではありません」	正式なモデルは仕様です — これらは実装ではなく、意図された動作を説明します	.pvおよび.spthyファイルに仕様ワークフロー（S1–S5）を使用

---

ワークフロー

Protocol Diagram Progress:
- [ ] Step 0: 入力タイプを確定（コード / 仕様 / 両方）
- [ ] Step 1（コード）またはS1–S5（仕様）: プロトコル構造を抽出
- [ ] Step 6: sequenceDiagramを生成
- [ ] Step 7: 検証して配信

---

Step 0: 入力タイプを確定

何をする前に、入力を分類してください：

信号	入力タイプ
ソースファイルの拡張子（.py、.rs、.go、.ts、.js、.cpp、.c）	コード
関数/クラス定義、インポートステートメント	コード
RFCスタイルのセクションヘッダー（§、Section X.Y、MUST/SHALLキーワード）	仕様
Algorithm/Protocol/Figureラベル、数学記法	仕様
ProVerifファイル（.pv）でprocess、let、in/out	仕様
Tamarinファイル（.spthy）でrule、--[...]->	仕様
プロトコルを説明する通常の記述または番号付きステップ	仕様
ソースファイルと仕様ドキュメントの両方	両方（⚠️で逸脱をアノテート）

• コードのみ → 下記Step 1にスキップ
• 仕様のみ → 仕様ワークフロー（S1–S5）にスキップ
• 両方 → 仕様ワークフローを最初に実行し、コード読み取りステップを使用して実装を仕様図に照らして検証し、⚠️で逸脱をアノテート
• 曖昧 → ユーザーに問い合わせ：「これはソースコードファイル、仕様ドキュメント、またはその両方ですか？」

---

Step 1: プロトコルエントリポイントを特定

関数名、型名、およびプロトコルを明らかにするコメントをGrep：

# ハンドシェイク、セッション、ラウンド、フェーズエントリポイントを検索
rg -l "handshake|session_init|round[_0-9]|setup|keygen|send_msg|recv_msg" {targetDir}

# 使用中の暗号化プリミティブを検索
rg "sign|verify|encrypt|decrypt|dh|ecdh|kdf|hkdf|hmac|hash|commit|reveal|share" \
    {targetDir} --type-add 'src:*.{py,rs,go,ts,js,cpp,c}' -t src -l

最高レベルのオーケストレーション関数から読み始めてください — ハンドシェイクフェーズまたはメインプロトコルループに呼び出すもの。

Step 2: 関係者と役割を特定

以下から参加者名を抽出：

• 構造体/クラス名：Client、Server、Initiator、Responder、Prover、Verifier、Dealer、Party、Coordinator
• 役割のステートを保持する関数パラメータ名
• 役割を宣言するコメント
• 2者または N 者シナリオをセットアップするテストフィクスチャ

これらをMermaidのparticipant宣言にマップします。短くて読みやすいエイリアスを使用：

participant I as Initiator
participant R as Responder

Step 3: メッセージフローをトレース

状態遷移とネットワーク送受信をたどります。以下のようなパターンを探します：

パターン	意味
send(msg) / recv()	直接メッセージ交換
serialize + transmit	送信された構造化メッセージ
他の関係者の関数に渡される戻り値	論理的メッセージ（プロセス内）
round1_output → round2_input	ラウンドベースのMPCステップ
ephemeral_key、ciphertext、mac、tagという名前の構造体フィールド	メッセージの内容

プロセス内プロトコル実装（両方の関係者が同じプロセスで実行される場合）の場合、役割境界での関数呼び出しを、配置時にネットワーク境界を表すときの論理的メッセージ送信として扱います。

Step 4: 暗号化操作をアノテート

各プロトコルステップで、以下を識別およびラベル付けします：

操作	図のアノテーション
キー生成	Note over A: keygen(params) → pk, sk
DH / ECDH	Note over A,B: DH(sk_A, pk_B)
KDF / HKDF	Note over A: HKDF(ikm, salt, info)
署名	Note over A: Sign(sk, msg) → σ
検証	Note over B: Verify(pk, msg, σ)
暗号化	Note over A: Enc(key, plaintext) → ct
復号化	Note over B: Dec(key, ct) → plaintext
コミットメント	Note over A: Commit(value, rand) → C
ハッシュ	Note over A: H(data) → digest
秘密共有	Note over D: Share(secret, t, n) → {s_i}
閾値結合	Note over C: Combine({s_i}) → secret

アノテーションは簡潔に — コードではなく数学的速記法を使用します。

Step 5: プロトコルフェーズを特定

メッセージステップをrectまたはNoteブロックを使用して名前付きフェーズにグループ化：

検出する共通フェーズ：

• Setup / Key Generation: 関係者キー作成、信頼されたセットアップ、パラメータ生成
• Handshake / Init: 一時的キー交換、ナンス交換、バージョンネゴシエーション
• Authentication: アイデンティティ証明、証明書交換、署名検証
• Key Derivation: 共有秘密からのセッションキー導出
• Data Transfer / Main Protocol: 暗号化されたアプリケーションデータ交換
• Finalization / Teardown: セッション閉鎖、MAC検証、中止処理

中止/エラーパスを検出し、altブロックで表示します。

---

仕様ワークフロー（S1–S5）

入力がソースコードではなく仕様ドキュメントの場合にこのパスを使用します。S1–S5を完了した後、上記のコードワークフローからStep 6（sequenceDiagramを生成）とStep 7（検証して配信）を続行します。

Step S1: 仕様を読み込む

完全な仕様テキストを入手：

• ファイルパスが提供 → Readツールで読む
• URLが提供 → WebFetchで取得
• インラインで貼り付け → 会話コンテキストから直接作業

次に、仕様形式を特定し、 references/spec-parsing-patterns.md を読んで、形式固有の抽出ガイダンスを取得：

形式	信号
RFC	RFC XXXX、MUST/SHALL/SHOULD、ABNF文法、セクション番号付き記述
学術論文 / 疑似コード	Algorithm X、Protocol X、Figure X、番号付きステップ、数学モードの←/→
通常の記述	番号付きリスト、「AはBに送る...」、プレーンな英語記述
ProVerif (.pv)	process、let、in(ch, x)、out(ch, msg)、!（レプリケーション）
Tamarin (.spthy)	rule、--[ ]->, Fr(~x)、!Pk(A, pk)、In(m)、Out(m)

仕様が既知の名前付きプロトコル（TLS、Noise、Signal、X3DH、Double Ratchet、FROST）を参照している場合は、 references/protocol-patterns.md も読んで、その正規フローをスケルトンとして使用し、仕様固有の詳細を入力します。

Step S2: 関係者と役割を抽出

すべてのプロトコル参加者を特定します。以下を探します：

• 名前付きの役割 記述または疑似コード内：Alice、Bob、Client、Server、Initiator、Responder、Prover、Verifier、Dealer、Party_i、Coordinator、Signer
• セクションヘッダー: 「Parties」、「Roles」、「Participants」、「Setup」、「Notation」
• ProVerif: トップレベルでのプロセス名（let ClientProc(...)、let ServerProc(...)）
• Tamarin: ルール名とファクト引数（例：!Pk($A, pk) — $Aは関係者）

各役割をMermaidのparticipant宣言にマップします。短いIDと記述的なエイリアスを使用（ references/mermaid-sequence-syntax.md の命名規則を参照）。

Step S3: メッセージフローを抽出

各関係者が誰に何を送るのか、そしていかなる順序で送るのかをトレース。形式別の抽出パターン：

RFC / 通常の記述:

• 矢印記号：A → B: msg、A -> B
• 文のパターン：「AはBに送る...」、「Bは...で応答」、「Aは...を送信」、「Xを受け取ると、BはY送信」
• 番号付きステップ：順序で抽出、コンテキストから送信者/受信者を推測

疑似コード:

• sender/receiverパラメータを持つ明示的な関数署名
• send(party, msg) / receive(party)呼び出し
• 次のステップで他の関係者の関数への入力として渡される戻り値

ProVerif (.pv):

• out(ch, msg) — チャネルchに送信
• in(ch, x) — チャネルchから受信、xにバインド
• 同じチャネルでout/inペアをマッチしてメッセージフローを識別
• !（レプリケーション）— 複数のセッションを処理する役割を示す

Tamarin (.spthy):

• In(m)前提 — メッセージmを受信
• Out(m)結論 — メッセージmを送信
• ルール名とルールの順序はプロトコルラウンドを示す
• Fr(~x) — 関係者によって生成された新しいランダム値
• --[ Label ]-> ファクト — セキュリティアノテーション、メッセージではない

順序とラウンド構造を保持します。最終図でparブロックを使用して同時送信（ブロードキャスト）をグループ化します。

Step S4: 暗号化操作を抽出

各プロトコルステップで、実行される暗号化操作と実行する関係者を特定：

仕様記法	操作	図のアノテーション
keygen()、Gen(1^λ)	キー生成	Note over A: keygen() → pk, sk
DH(a, B)、g^ab	DH / ECDH	Note over A,B: DH(sk_A, pk_B)
KDF(ikm)、HKDF(...)	キー導出	Note over A: HKDF(ikm, salt, info) → k
Sign(sk, m)、σ ← Sign	署名	Note over A: Sign(sk, msg) → σ
Verify(pk, m, σ)	検証	Note over B: Verify(pk, msg, σ)
Enc(k, m)、{m}_k	暗号化	Note over A: Enc(k, plaintext) → ct
Dec(k, c)	復号化	Note over B: Dec(k, ct) → plaintext
H(m)、hash(m)	ハッシュ	Note over A: H(data) → digest
Commit(v, r)、com	コミットメント	Note over A: Commit(value, rand) → C
ProVerif senc(m, k)	対称暗号化	Note over A: Enc(k, m) → ct
ProVerif pk(sk)	公開鍵導出	Note over A: pk = pk(sk)
ProVerif sign(m, sk)	署名	Note over A: Sign(sk, m) → σ

セキュリティ条件と中止パスを特定：

• 記述：「検証に失敗したら中止」、「～の場合のみ」、「～の場合は拒否」
• 疑似コード：assert、require、if ... abort
• ProVerif：if m = expected then ... else 0
• Tamarin：矛盾するファクトまたは制限補題

これらは最終図のaltブロックになります。

Step S5: 仕様の曖昧さにフラグを立てる

Step 6に進む前に、ギャップをチェック：

• 不明確なメッセージ順序：ラウンド構造またはセクション順序から推測；⚠️ ordering inferred from spec structureでアノテート
• 暗黙的な関係者：役割が暗黙的だが名前がない場合は、記述的な名前を付け、推論に注記
• 欠落ステップ：仕様がこのプロトコルの正規パターンが必要とするステップを省略している場合、アノテート：⚠️ spec omits [step] — canonical protocol requires it
• 不十分に指定された暗号化：仕様がスキームを指定せずに「暗号化」と言う場合、アノテート：⚠️ encryption scheme not specified
• ProVerif/Tamarin：プライベートチャネル（new cで宣言またはプライベート自由名として）はオフバンドチャネルを表す — 注記

---

<!-- コードパス（Steps 1–5）と仕様パス（Steps S1–S5）の両方がここで続行 -->

Step 6: sequenceDiagramを生成

references/mermaid-sequence-syntax.md のルールに従うMermaid構文を作成します。

簡潔性よりも完全性。 すべての異なるメッセージタイプを表示します。繰り返されるループイテレーション（loopブロックを使用）は省略していますが、異なるプロトコルステップを省略しないでください。

美学よりも正確性。 図はコードが実際に何をするかと一致する必要があります。コードが既知の仕様から逸脱している場合は、逸脱をアノテート：

Note over A,B: ⚠️ spec requires MAC here — implementation omits it

Step 7: 検証して配信

配信前に確認：

• 宣言されたすべての参加者が少なくとも1つのメッセージを送受信する
• 矢印は正しい方向（送信者 → 受信者）を指す
• 暗号化操作は正しい関係者（計算している関係者）の上にある
• プロトコルフェーズが使用されている場合、フェーズブロック外に矢印がない
• altブロックは既知の中止/エラーパスをカバー
• 図がエラーなしでレンダリングされる（ references/mermaid-sequence-syntax.md で一般的な落とし穴をチェック）
• 仕様逸脱が見つかった場合、⚠️でアノテート

図をファイルに書き込みます。 プロトコル名から派生したファイル名を選択します（例：noise-xx-handshake.mdまたはx3dh-key-agreement.md）。この構造を持つMarkdownファイルを書き込む：

# <Protocol Name> Sequence Diagram

\`\`\`mermaid
sequenceDiagram
    ...
\`\`\`

## Protocol Summary

- **Parties:** ...
- **Round complexity:** ...
- **Key primitives:** ...
- **Authentication:** ...
- **Forward secrecy:** ...
- **Notable:** [仕様逸脱またはセキュリティ観察、または「none」]

ファイルを書き込んだ後、ASCIIシーケンス図をインラインで応答に出力し、その後にProtocol Summaryを続けます。ユーザーがMermaidソースを見つけられるように出力ファイル名を述べます。

references/ascii-sequence-diagram.md のすべての描画規則に従います。これはインライン出力形式を含みます。

---

判定木

── 入力は仕様ドキュメント（コードではない）？
│  └─ Step S1: 形式を特定、references/spec-parsing-patterns.md を読む
│
── 入力はソースコード（仕様ではない）？
│  └─ Step 1: handshake/round/send/recv エントリポイント用に grep
│
── 仕様とコードの両方が提供？
│  └─ 仕様ワークフロー（S1–S5）を最初に実行して正規図を構築、
│     その後コードを読んで ⚠️ で逸脱をアノテート
│
── 仕様は既知のプロトコル（TLS、Noise、Signal、X3DH、FROST）？
│  └─ references/protocol-patterns.md を読んで正規フローをスケルトンとして使用
│
── 仕様は ProVerif (.pv) または Tamarin (.spthy)？
│  └─ references/spec-parsing-patterns.md を読む → Formal Models セクション
│
── 仕様メッセージ順序は曖昧？
│  └─ ラウンド/セクション構造から推測、⚠️ でアノテート
│
── 仕様から関係者を特定できない？
│  └─ 「Parties」/「Notation」セクションをチェック；ProVerif はプロセス名を読む；
│     Tamarin はルール名とファクト引数を読む
│
── プロトコルを実装するコードファイルがわからない？
│  └─ Step 1: handshake/round/send/recv エントリポイント用に grep
│
── 構造体名から関係者を特定できない？
│  └─ テストファイルを読む — テストセットアップは役割を明らかにする
│
── プロトコルはプロセス内で実行される（ネットワーク呼び出しなし）？
│  └─ 役割境界でのファイアー引数渡しをメッセージとして扱う
│
── MPC / 閾値プロトコル（N者）？
│  └─ references/protocol-patterns.md を読む → MPC セクション
│
── Mermaid 構文エラー？
│  └─ references/mermaid-sequence-syntax.md を読む → Common Pitfalls
│
└─ ASCII 描画規則？
   └─ references/ascii-sequence-diagram.md を読む

---

例

コードパス — examples/simple-handshake/:

• protocol.py — 2者認証キー交換（X25519 DH + Ed25519署名 + HKDF + ChaCha20-Poly1305）
• expected-output.md — そのプロトコルに対してスキルが生成すべき正確なASCII図とMermaidファイル

仕様パス（ProVerif） — examples/simple-proverif/:

• model.pv — ProVerifでモデル化されたHMACチャレンジ-レスポンス認証
• expected-output.md — ステップバイステップ抽出ウォークスルー（関係者、メッセージフロー、暗号化操作）とスキルが生成すべき正確なASCII図とMermaidファイル

なじみのない入力を処理する前に、関連する例を研究してください。

---

サポートドキュメント

• references/spec-parsing-patterns.md — RFC、学術論文/疑似コード、通常の記述、ProVerif、Tamarin入力形式の抽出ルール；Step S1で読む
• references/mermaid-sequence-syntax.md — 参加者構文、矢印タイプ、アクティベーション、グループ化ブロック、エスケープ規則、および一般的なレンダリング落とし穴
• references/protocol-patterns.md — TLS 1.3、Noise、X3DH、Double Ratchet、Shamir秘密共有、commit-reveal、および一般的なMPCラウンドの正規メッセージフロー；実装を仕様と比較するときにリファレンスとして使用
• references/ascii-sequence-diagram.md — 列レイアウト、矢印規則、自己ループ、フェーズラベル、およびASCII図のインライン出力形式