constant-time-analysis

constant-time-analysis skill の概要

constant-time-analysis は、暗号コードに潜むタイミング・サイドチャネルのリスクを、実際に悪用可能なバグになる前に見つけるためのセキュリティ監査向けスキルです。秘密依存の計算、分岐、比較、実行時命令が、鍵やトークン、その他の機微情報を漏らしていないかを確認したいエンジニア、レビュー担当者、AI エージェントに最適です。

ここでの主な役割は「暗号理論を理解する」ことではなく、「このコードがどこで constant-time でなくなるかを見つける」ことです。そのため、constant-time-analysis skill は、実装レビュー、マージ前のセキュリティチェック、そして「この関数はタイミング攻撃に対して安全か」と問われるインシデントの切り分けで特に有効です。

汎用プロンプトとの違いは、ソースだけを眺めるのではなく、コンパイル後の出力と各言語に応じた解析経路を前提にしている点です。constant-time の問題は、ソースコード上は無害に見えても、アセンブリ、バイトコード、VM 命令の中で初めて表面化することが多いため、この違いは重要です。

セキュリティ監査での constant-time-analysis の最適な用途

次のようなコードをレビューするときに使ってください。

• secret、認証、暗号プリミティブを扱う
• secret 由来の値に対して、除算、剰余、比較、分岐を使う
• ソースの意図だけでなく、コンパイル済み成果物まで含めて検証する必要がある
• C、C++、Go、Rust、Swift、Java、Kotlin、PHP、JavaScript、TypeScript、Python、Ruby を対象にしている

何を検出できて、何を見落としやすいか

constant-time-analysis は、可変時間の除算、secret 依存の分岐、危険な比較といったタイミング漏えいパターンに強いです。一方で、暗号設計上の広い意味でのミス、プロトコル上の欠陥、あるいはネットワーク、キャッシュ、環境ノイズ由来の漏えいには弱めです。ただし、それらの問題が解析対象のコードパスに実際に現れている場合は別です。

なぜ導入するのか

手作業でざっと見るよりも早い段階でタイミング・リスクを拾える、再現性のあるレビュー手順が欲しいなら、このスキルを導入する価値があります。単発のスニペットについて一度だけ意見が欲しいなら通常のプロンプトで足りることもありますが、継続的に同じ品質でセキュリティレビューをしたいなら、スキルによって手順が明確になります。

constant-time-analysis skill の使い方

正しくインストールして起動する

スキルマネージャーから constant-time-analysis のインストール手順を使い、対象言語と機微な関数やファイルを含む文脈で実行してください。良いトリガー・プロンプトでは、暗号の目的、secret 入力、言語／ランタイムを明示して、スキルが適切な解析経路を選べるようにします。

トリガー例:

• “Review src/sign.rs for constant-time risk. Secret input is the private key scalar; focus on division, branches, and comparisons.”
• “Run constant-time-analysis on this PHP password-checking function and tell me whether any opcode-level timing leak is likely.”

スキルに適切な入力形を渡す

このスキルは、次の情報があると最もよく機能します。

• どのファイル／関数を確認するか
• どの値が secret か
• どのような攻撃者観測可能な挙動が問題か
• 既知であれば、対象の言語とランタイムのバージョン

より良い入力例:

• “Audit verifyToken() in TypeScript. Token bytes are secret; compare against stored HMAC; check for Div, Mod, and early-exit comparisons.”
• “Analyze this Rust reduce() routine for secret-dependent division across x86_64 and arm64.”

まず読むべきファイル

導入判断と作業フローの確認は、まず次のファイルから始めてください。

• SKILL.md — トリガー、スコープ、言語選択
• README.md — 対応言語と出力目標
• references/compiled.md — C/C++、Go、Rust
• references/javascript.md, references/python.md, references/php.md, references/ruby.md, references/swift.md, references/kotlin.md — VM 固有のルール

参照ファイルを1つだけ拾うなら、ソース言語のラベルではなく、実際のランタイム経路に合うものを選んでください。

1回で終わらせず、レビュー手順として使う

実用的な constant-time-analysis の使い方は、次の流れです。

1. secret を含む関数を特定する
2. 該当する言語ガイドを実行する
3. 除算、剰余、比較、分岐、怪しいヘルパー呼び出しを確認する
4. リファクタ後やコンパイラ／ランタイム変更後に再実行する
5. 結果を機械判定したいなら CI 向け出力を要求する

ソース上で修正できても、特にコンパイル言語では、安全でない命令列に変換されることがあるためです。

constant-time-analysis skill FAQ

constant-time-analysis は暗号専用ですか？

いいえ。secret データに対するタイミング差が問題になるコードなら何でも対象です。ただし、実際には暗号、認証、鍵の取り扱い、トークン検証で使われることがほとんどです。公開データしか扱わないコードなら、このスキルはたいてい不要です。

アセンブリやバイトコードの知識は必要ですか？

最初から必須ではありません。このスキルは、適切なランタイム成果物と言語別リファレンスへ誘導してくれる点に価値があります。すべての命令を読めなくても構いませんが、どの関数やファイルがセキュリティ上重要かは把握しておく必要があります。

constant-time-analysis は通常のプロンプトより優れていますか？

再現性のあるセキュリティレビューが必要な場合は、はい。通常のプロンプトでも目立つリスクは拾えますが、constant-time-analysis は言語選択、コンパイル後の出力、具体的な漏えいパターンを中心に構成されているため、リポジトリ作業ではより実用的です。

どんなときに使わないべきですか？

通常の業務ロジック、UI コード、公開データの変換には使わないでください。また、ライブラリ側で constant-time 動作が保証されており、自分で secret 依存ロジックを追加していない高レベル API の使い方だけを確認したい場合も、使わなくてよいことがあります。

constant-time-analysis skill を改善するには

secret と攻撃者モデルを絞り込む

最も精度の高い constant-time-analysis の結果は、「何を secret として守るべきか」と「攻撃者が何を観測できるか」を正確に書くことから得られます。リスクがリモートのタイミングなのか、ローカルプロセスのタイミングなのか、あるいはコンパイル済みコードの解析なのかを明示してください。そこが曖昧だと、無害な分岐ばかりに反応したり、逆に本当に重要な制約を見落としたりします。

リスクのある最小のコード経路を渡す

リポジトリ全体ではなく、secret データに実際に触れる関数を渡してください。ヘルパー関数は、分岐、算術、比較に影響する場合にだけ含めれば十分です。ノイズが減り、出力を実際の修正に結びつけやすくなります。

言語固有の根拠を求める

最良の結果を得るには、関連するランタイム成果物を確認するように依頼してください。

• C/C++、Go、Rust ならアセンブリ
• JavaScript、TypeScript、Python、Ruby、PHP ならバイトコード
• Kotlin なら JVM の挙動

タイミング漏えいはソースより下の層で起きることが多いため、これが constant-time-analysis の使い方を大きく改善します。

修正のたびに再実行する

よくある失敗は、ソースを直しただけで漏えいが消えたと思い込むことです。アルゴリズム、コンパイラフラグ、最適化レベル、ランタイムのバージョンを変えたら、必ず再テストしてください。セキュリティ監査向けの constant-time-analysis では、その2回目の確認で本当の安全性が見えてくることがよくあります。