← 2026-07-08 の一覧へ戻るホーム
AI と暗号化の融合 第1回：Cloudflare の Circl で見つかったものとは？

2026/07/08 3:36

AI と暗号化の融合 第1回：Cloudflare の Circl で見つかったものとは？

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

ZSecurity の AI 監査エージェント、zkao は、Cloudflare の実験的 CIRCL ライブラリに存在する 7 つの重大な暗号学上の脆弱性を特定し、修正に貢献しました。これらの発見は上流（本家）で確認され、特定のコミットハッシュとともに報告されています。従来の「LLM 専用」スキャナーとは異なり、zkao は AI モデルと専門家のスキルを組み合わせることで、RSA の評価における精度誤差やアクセス制御の破綻など、深い文脈が必要となる重大な欠陥を検出します。このアプローチは、汎用的なモデルが深刻なセキュリティ上の欠陥を見落したり、文脈に無意識の状態に留まったりしていたという以前の限界に対処しています。

本文

AI 監査パイプライン「zkao」による Cloudflare CIRCL における重大な脆弱性 7 つの発見と対策

zkSecurity が開発した AI 監査エージェント「zkao」を用いて、Cloudflare の実験的暗号学ライブラリ（CIRCL）を対象とした監査を実施しました。その結果、7 つの真の脆弱性を発見し、全ての上流プロジェクト（upstream）にて修正が進められています。

本記事は、オープンソース暗号学プロジェクト内での同様の脆弱性発見の一連の記事の第一弾です。zkao の開発目標は、AI にコードの監視を常態化させ、他の AI ツールでは見逃されがちな残存バグをゼロにすることにあります。

zkao：監査プロセスと動機

zkao の構築には以下の 2 つの主要な動機と目的があります。

  • 継続的な自己改善と自動化
    • AI で検出可能なあらゆるバグを発見できる「自動化監査者」を目指します。
    • 新規アイデアのブレインストーミング、専門知識の体系的な組み込み、バイアスの排除、そして何よりもモデルの進化を可視化するための実験が繰り返されます。
  • LLM の暗号学推論能力への洞察
    • LLM が暗号学をどのように理解し推論しているかを常に監視します。
    • 特に**「鋭い洞察力」と「盲点（Bias）」**、そしてこれらを強化・抑制する方法に注目を集めています。

脆弱性発見の実績と品質保証

過去数ヶ月間に行われた実験から、LLM 単独および「スキル付与型」の LLM でスキャンした結果、zkao は独自に複数の深刻な問題を特定しました。CIRCL には多数の候補的な発見があり、その中で報告に値するものとして 7 つを選択しました。

  • 現状: 全ての脆弱性が上流で修正済み。
  • 賞金プログラム: 大部分は HackerOne プログラム下での確認により、賞金が发放されました。

⚠️ 補足：AI の発見と人間による検証の重要性

AI は「候補的な発見（Suspected Finding）」を出力しますが、信頼できる報告書ではありません。人間による検証は以下の理由で必須です。

  • 悪用可能性の確認
  • POC（概念実証）の作成・最適化
  • 開示手続きの処理

現在の zkao はこの検証工程の一部を自動化しつつあり、将来的にさらにその割合を増やしてまいります。

脆弱性情報と修正の要約表

№脆弱性の概要AI の初動評価Cloudflare 修正時の評価修正コミットハッシュ発見者
1TSS/RSA: 
float64
を用いた多項式評価の精度損失		Critical (重大)Low (軽微)f7d2180Opus 4.6 + skills
2qndleq: Prover が制御する 
SecParam
を通じた証明偽造		High (高度)Low (軽微)757dde4Opus 4.6 + skills
3BLS: メッセージ一意性をチェックしない集約検証（不正鍵攻撃脆弱）Medium (中程度)High (高度)9798df7Opus 4.6 + skills
4qndleq: 
FillBytes
による符号衝突で DLEQ 健全性破壊		High (高度)Low (軽微)19848a5Opus 4.6 + skills
5HPKE: ビット演算 OR スイッチによる PSK 検証回避Medium (中程度)Medium (重複扱い)a3b4fa3GPT-5.3 + skills
6TSS/RSA: 
int64
を用いた Lagrange 係数計算問題（オーバーフロー）		High (高度)Medium (中程度)751e372Opus 4.6 + skills
7CP-ABE: AND-share のバグによるアクセス制御完全破壊Critical (重大)Critical (重大)def2fd3zkao (独自発見)

注釈: AI と開発チーム間の重症度評価のギャップについては後ほど詳細に論じます。現在、zkao は全ての脆弱性を再現可能であることが確認済みです。

各脆弱性の詳細分析

1. float64 を用いた多項式評価（TSS/RSA）

対象: CIRCL の閾値 RSA (

tss/rsa
) 
Deal()
関数において、秘密多項式の係数評価時に 
float64
（倍精度浮動小数点数）を使用していました。

  • 問題点: 
    float64
    は有効桁が 53 ビット（約 $2^{53}$）のため、これを超えると値が丸められてしまいます。
    • 例：プレイヤー数 100、インデックス 26 の場合、$100^{26} = 10^{52}$ とはなりませんでしたが、計算上の制約により $2^{53}$ を超える可能性があり、結果が不正確になります。
    • これにより、鍵共有情報が正しく生成されず、署名合成が失敗したり、意図しない鍵を構築したりするリスクが生じます。
  • 修正: 浮動小数点計算をHorner の法則を用いた整数演算に変更し、
    big.Int
    で処理するように修正（コミット f7d2180）。

2. Prover が制御するセキュリティパラメータを通じた証明偽造（qndleq）

対象: CIRCL の離散対数等値 (

zk/qndleq
) DLEQ 証明の検証において、
SecParam
フィールドが 
Proof
構造体の内部に格納されていました。

  • 問題点: 攻撃者は検証時に使用する 
    SecParam
    を自身で制御できます。 
    • SecParam = 1
      : チェallenge は単一ビットになり、偽造を試行錯誤で突破可能（確率攻撃）。
    • SecParam = 8
      : ブルートフォース攻撃で $2^8=256$ 回以内に突破可能。
    • これにより証明の健全性が損なわれます。
  • 修正: 
    SecParam
    を検証者へ渡すための明示的な引数に変更し、Prover 側での制御を排除（コミット 757dde4）。

3. メッセージ一意性をチェックしない BLS 集約検証（BLS）

対象: CIRCL の BLS 署名 (

sign/bls
) 
VerifyAggregate
関数がメッセージの一意性チェックを行っていませんでした。

  • 問題点: BLS 標準の「不正な鍵攻撃（Rogue Key Attack）」が可能になります。
    • 攻撃者は自身の公開鍵と被害者の公開鍵を組み合わせて、正当なように見える偽の署名を作成し、一意性の要件を回避します。
    • これによりCIRCL が提供する所有権証明（Proof-of-Possession）へのインフラストラクチャが無効化されます。
  • AI の評価と実際: AI はこれを「Medium」と評価しましたが、Cloudflare と zkSecurity はHigh/Criticalとし、脆弱性の性質（教科書的な攻撃手法）から即座に修正しました。
  • 修正: 重複メッセージを含むバッチを拒否するようロジックを追加（コミット 9798df7）。

4. FillBytes による符号衝突と DLEQ の健全性破壊（qndleq）

対象: CIRCL の離散対数等値 (

zk/qndleq
) 
FillBytes
（シリアライズ関数）での整数の絶対値計算による影響です。

  • 問題点: 正当な証明 $(\pi, S_1)$ が、攻撃者の意図した別の文書 $S_2$（符号が逆転したもの）においても検証されてしまうバグです。
    • 代数的要因: $(-g_x)^c = (-1)^c \cdot g_x^c$ であり、偶数 $c$ の場合符号因子が消滅します。
    • ハッシュ要因: 
      FillBytes
      は絶対値を使用するため、負の値も正と同じハッシュ処理となります（ただし完全一致しないため確率的な攻撃）。
    • 攻撃者は約半数の試行で正当な証明を受け付ける状態に置けます。
  • 修正: チェallenge 計算前に 
    checkBounds
    を導入し、入力範囲 $0 < x < N$ を厳格に強制（コミット 19848a5）。

5. ビット演算 OR スイッチによる HPKE PSK 検証回避（HPKE）

対象: CIRCL の HPKE (

hpke/util
) 
verifyPSKInputs
のスイッチケースでビット演算 
|
を使用していたことです。

  • 問題点: Go のケース文法において、
    case A | B:
    は 1 つの定数として扱われます。 
    • case modePSK | modeAuth:
      は実質的に 
      modeAuth
      だけをマッチさせ、
      modePSK
      ブランチはスキップされてしまいます。
    • PSK 材料がない場合でも「空（nil）」として処理され、認証条件が静かに無視され、セキュリティ強度の低いモードで実行されてしまいます。
  • 修正: OR 演算をカンマ区切りのケースに書き換える一行変更（
    case modePSK, modeAuth:
    ）で解決（コミット a3b4fa3）。

6. int64 を用いた Lagrange 係数計算問題（TSS/RSA）

対象: CIRCL の閾値 RSA (

tss/rsa
) Lagrange 補間計算において、分子と分母を 
int64
で保持していました。

  • 問題点: 2 つの独立したバグが含まれています。
    1. オーバーフロー: プレイヤー数が多すぎると積が 
      int64
      の上限を超え、符号付き整数に変換されてしまいます（Go ではパニックしないため静かにエラー処理されます）。
    2. 切り捨て: 非連続な共有インデックスにおいて、先に除算を行うと割り切れず、値が不正確になります。
  • 修正: 全てを 
    big.Int
    に置き換え、乗算と除算の順序を調整して正確性を担保（コミット 751e372）。

7. CP-ABE アクセス制御破壊（AND-share のバグ）

対象: CIRCL の属性に基づく暗号化 (

abe/cpabe/tkn20
) zkao が独自に発見した、アクセス制御保証を完全破綻させる重大なバグです。

  • 仕組み: CP-ABE では、AND ゲートで各秘密鍵を部分的に分断し（$r, parent-r$）、組み合わせてのみ復号できるようにします。
  • 問題点: AND ゲートの処理において、片方の入力（
    In1
    ）をゼロに固定し、もう片方（
    In0
    ）に完全なシークレット 
    parent
    を代入していました。
    • これにより、**「AND」ではなく「OR」**の論理になってしまい、片方の鍵だけでメッセージを復号できてしまいます。
  • 致命的性: この破綻した AND ゲートが、Boneh-Katz 変換によるセキュリティ強化回路の外部ゲートとして使われていたため、全ての属性鍵が単独でメッセージ鍵を再構築でき、機密性が完全に失われました。
  • 修正: AND ゲートの両方の子ノードに正しい部分共有を与えるロジックに戻す一行変更（コミット def2fd3）。

考察：私たちから学んだこと

今回の監査を通じて、AI の限界と可能性、そしてセキュリティ評価における重要な知見が得られました。

1. AI の重症度判断は不対称である

  • 過大評価: 多くのバグ（例：
    float64
    パラメータ問題）を 
    Critical
    と判断しましたが、実際には影響範囲が限定的でした（
    Low
    ）。
  • 過小評価: BLS の一意性欠如など、教科書的な攻撃が可能で「Major/Critical」であるべきものを 
    Medium
    と判断しました。
  • 課題: LLM は「下流での影響」や「セキュリティ文脈」を十分に理解していないため、人間による最終検証が必須です。

2. モデルペアリングは動的で非対称である

  • 今回の監査では 
    Claude Opus 4.6 + スキル
    の組み合わせが主要な発見源となりました。
  • しかし、数ヶ月後には GPT モデルの方が多くのバグを発見し、検証役になり得ることが確認されました。特定のモデルに固執せず、最適なペアリングを常に見直す必要があります。

3. AI は問題を見つけ、連鎖させることは難しい

  • バグ 6（Lagrange）のように、オーバーフローと切り捨ての両面という独立した事実を見つけてくれました。
  • しかし、それらを単一の問題として束ね、相互関係や「より深い悪用」として連結させる段階は AI に限界的です。これこそ人間の役割です。

今後の展望

CIRCL のメンテナーには感謝申し上げます。報告された問題の全ての対応が迅速に完了しました。 現在、200 を超える暗号学プロジェクトをスキャンし、1,000 件以上の候補的な発見を行いました。現在のボトルネックは**「人的なタスク管理（Triage）」**であり、自動化プロセスの強化が続いています。

** zkSecurity **として、私たちは「zkao」をさらに進化させ、以下の点に注力します。

  • モデル非依存性: 特定の AI に依存せず、最適なパフォーマンスを維持。
  • エンドツーエンドな脆弱性報告: 単なるバグの発見から、実用的な POC と脅威モデリングまでを自動化。
  • コミュニティとの連携: 開発者に安全なコーディングを支援し、重大なバグが早期に解消される環境を作る。

継続的な AI カバーをお考えの方は、zksecurity.xyz/contact よりお問い合わせください。

同じ日のほかのニュース

一覧に戻る →

2026/07/08 3:24

Kokoro を活用したローカル動作・CPU対応で高品質な TTS（テキスト対話）

## Japanese Translation: 2026 年 3 月 31 日にリリースされた Kokoro-82M は、わずか 8200 万パラメータだけで英語・中国語・ヒンディー語の極めてリアルな声を生成する特段に軽量な Text-to-Speech モデルです。CPU 上で完結するように設計されており、高価な GPU の依存を回避できます（GPU はローカルの LLL推論用に留保されます）。同モデルは AMD Ryzen チップを搭載した標準的なプロセッサ、Intel Core i7 システム、Apple M シリーズ CPU にもデプロイ可能です。ベンチマーク結果では、各種ハードウェア上で合成時間が 5 秒以内となっています：Intel Core i7-4770K で約 4.7 秒、Apple M2 Pro で 4.5 秒、短かい段落では AMD Ryzen 7 8745HS で低至くとも 1.5 秒です。 最も簡単なデプロイ方法では、プリダウンロード済みの音声モデルを含む Kokoro-FastAPI コンテナイメージ（約 5 GB）を使用します。ユーザーは `podman run -p 8880:8880 ghcr.io/remsky/kokoro-fastapi-cpu` コマンドで Podman を使用してサービスを開始し、`localhost:8880/web` でウェブ UI にアクセスすることで、オーディオを直接生成・再生できます。コンテナは OpenAI 互換の音声 API を公開しており、JavaScript（`./speak.js`）および Python（`./speak.py`）スクリプトなどの実装例があります。音声モデルは環境変数 `TTS_VOICE` を使用して選択でき（全リストは HuggingFace で確認可能）、出力は MP3 ファイルとして保存され、SoX がインストールされている場合は自動再生も可能です。 音声認識と Text-to-Speech の両方が必要なアプリケーション向けには、オプションの Speaches コンテナ化サービスが Whisper とシームレスに統合され、また OpenAI API 互換性もサポートしています。リソース要求を低く抑えつつ、簡潔なデプロイオプションを提供することで、Kokoro-82M は自然で多言語の音声合成を開発者のワークフローや広範なアプリケーションに統合するためのハードルを大幅に低下させます。

2026/07/07 21:38

StreetComplete：1 つの小さなクエストで OpenStreetMap を修正していくプロジェクト

## Japanese Translation: StreetComplete は、誰でも現在地から OpenStreetMap の精度を向上させるシンプルな方法を提供します。アプリは生地図上に不足している情報を簡単な「クエスト」として表示し、利用者に特定の場所を訪れて短く質問に答えるよう促し、データギャップを埋めます。このアプローチにより、高度な編集スキルや専用ソフトがなくても OpenStreetMap が最新の状態を保つことができます。ユーザーがタスクを完了すると、その貢献は瞬時にグローバルデータベースで更新され、直ちにその名前でクレジットされます。このメカニズムにより、地図の改善は情報を収集した実際の観察者まで追跡可能になります。したがって、ナビゲーションや地域発見のためのストリートレベルの詳細はより正確かつ信頼性が高まります。究極的には、このツールはマッピングを民主化し、無関心な訪問者を能動的な貢献者に転換させます。これにより、遠隔編集や大規模な専門チームに依存することなく、簡単な現場での相互作用を通じて正確な地理データが継続的に拡張されるコミュニティが育まれます。

2026/07/07 23:23

Chat Control バージョン 1.0 と 2.0 の解説

## Japanese Translation: 欧州連合（EU）は、企業に対し、子供による性虐待資料（CSAM）を検出するために私信をスキャンすることを義務付ける有効期限を迎えた暫定権能（チャットコントロール 1.0，規制 EU 2021/1232）の復活を図ろうとしている。当初 2024 年 8 月 3 日に有効期限が切れる予定だったこの措置は、2 回延期された——最初に 2026 年 4 月 3 日（2024 年 4 月 29 日の議決）、続いてさらに 2028 年 4 月まで（2025 年 12 月 18 日の提案）。2026 年 3 月 26 日、下院での投票で改正案 34 が否決されず、その一方で不特定の写真やテキストの自動評価を禁止する改正案 34 が僅差（307 対 306）で可決されたことを受け、無効化措置に基づく自発的スキャンの法的根拠は 2026 年 4 月 4 日に終了した。にもかかわらず、主要プラットフォーム（Google、Meta、Microsoft、Snap）は自発的に引き続きスキャンを行うと発表した。 しかし、立法上の行き違いが生じている：欧州議会の LIBE 委員会は 2026 年 3 月 2 日に延期を拒否し、欧州議会は 2026 年 3 月 11 日、広範な自動分析に対する保護性指令を採用し、理事会は同年 3 月中旬に欧州議会の条件を拒否した。これに対し、EU の大使たちは 2026 年 6 月 26 日に手続の簡素化を通じて暫定復活を推進することに合意し、理事会は同年 7 月 2 日にも自らの立場を採用した。2026 年 7 月 7 日、欧州議会は緊急手続を承認するため 331 対 303 の投票を行い、その際に関連する委員会を bypass して、有効期限を迎えた特別措置を迅速処理する手続きをとった。この議題に対する法的拘束力のある投票は木曜日（7 月 9 日）に予定されており、絶対多数である 361 人の欧州議会議員の賛成が必要となる。 同時に、「チャットコントロール 2.0」と呼ばれる恒久解決策を確立するための努力も停滞している。委員会は 2022 年 5 月 11 日、プラットフォームに対し暗号化全体（エンドツーエンド）を迂回して検出と報告を行うことを求める恒久規制を提案した。2023 年 11 月、欧州議会は E2E スキャンに反対する保護性指令を採用し、視覚情報のみを対象とした分析、特定の裁判所命令の要件のみを受け入れること、また年齢認証の義務化を拒否することを要請した。2025 年 12 月から 2026 年 5 月までの 4回のトリログ（三回協議）ラウンドに加えて、2026 年 6 月 29 日の「最終」ラウンドも失敗に終わったが、チャットコントロール 2.0 に関する合意は依然として達されていない。 2026 年 6 月 10 日、理事会の法務部は、裁判所の承認なしに行われる自発的スキャンは、EU 基本権憲章第 7 条（プライバシーとデータ保護）に抵触する一般化されたスキャンであるとして警告した。恒久 CSA 規制について 5回のトリログラウンドが完了後なお合意に至らず、2025 年 10 月にドイツの議長国としての任務でリスク評価と軽減義務への重点が移行している状況において、EU は児童安全の強化とデジタル権限の維持という狭いバランスを navigate しなければならない。7 月 9 日の緊急投票は、国家関連のスキャン手続に議論を伴う形で再び導入することを強いるリスクがあり、これにより憲法上の保護や公共の信頼に関連する新たな法的課題が引き起こされる可能性がある。