中国の次世代暗号の標準化候補、署名・KEM・鍵交換・ハッシュで問題

セキュリティニュース

投稿日時: 更新日時:

中国の次世代暗号の標準化候補、署名・KEM・鍵交換・ハッシュで問題

中国の「Next-generation Commercial Cryptographic Algorithms Program（NGCC）」に提出された暗号アルゴリズム候補について、独立検証サイト「ngcc.dev」が2026年9月21日、複数の設計・実装上の問題を公開しました。

ngcc.devの2026年9月21日18時31分UTC時点の一覧では、デジタル署名34候補、鍵カプセル化メカニズム（KEM）41候補、鍵交換9候補、ハッシュ35候補の計119候補を掲載しています。このうち34候補について48件の指摘が公開され、44件は「Confirmed」、2件は「Probable」、1件は「Lead」、1件は「Proof gap」と分類されています。

深刻度別ではCriticalが18件、Highが20件、Mediumが8件、Lowが2件です。Criticalには、任意の署名を受け入れる検証処理、公開情報だけで共有秘密を復元できるKEM実装、再現可能な秘密鍵、ハッシュ衝突などが含まれています。

ただし、ngcc.devは中国の商用密码标准研究院（Institute of Commercial Cryptography Standards：ICCS）やNGCCの公式評価機関ではありません。同サイト自身も「NICCSとは提携していない」と明記しています。また、一覧の「No report」は安全性が確認されたことを意味せず、「この独立プロジェクトが攻撃レポートを公開していない」という意味です。

NGCC候補は標準として採用済みの暗号ではなく、現在評価中の候補です。今回のレポートは候補アルゴリズムの絞り込みや修正に使われる段階での第三者評価として見る必要があります。

NGCC独立検証レポートのサマリー

確認できている内容：

  • NGCCは、中国のICCSが2025年2月に開始した次世代商用暗号アルゴリズムの募集・評価プログラムです。
  • ICCSは量子コンピューターの脅威への対応と次世代商用暗号の標準化を目的としてNGCCを開始しました。
  • ngcc.devはNGCC候補を独立検証するプロジェクトで、ICCS/NICCSとは提携していません。
  • 2026年9月21日18時31分UTC時点で、ngcc.devには119候補が掲載されています。
  • 34候補について48件の指摘が公開されています。
  • 48件のうち44件がConfirmed、2件がProbable、1件がLead、1件がProof gapです。
  • 深刻度ではCritical 18件、High 20件、Medium 8件、Low 2件です。
  • Criticalには、署名検証が常に成功する実装、秘密鍵を再現できる実装、共有秘密を公開情報だけで復元できるKEMなどが含まれます。
  • 公開レポートの多くは、提出者が公開した仕様書とリファレンス実装を対象にしています。
  • ngcc.devは再現用の「ngcc-harness」をGitHubで公開し、ICCS公式APIを使って候補実装をビルド・テストしています。
  • 各レポートにはMarkku-Juhani O. Saarinen氏がクレジットされ、「with AI assistance」と記載されています。
  • Saarinen氏はフィンランド・Tampere UniversityのProfessor of Practiceで、暗号・情報セキュリティを専門としています。
  • 9月22日時点で、ICCS公式サイト上にngcc.devの指摘全体に対する公式見解や修正状況の一覧は確認できませんでした。
項目 内容
対象 NGCC Round 1候補
独立検証 ngcc.dev
一覧更新 2026年9月21日 18:31:51 UTC
掲載候補 119
指摘が公開された候補 34
指摘総数 48
Confirmed 44
Probable 2
Lead 1
Proof gap 1
Critical 18
High 20
Medium 8
Low 2
公式評価か いいえ。ICCS/NICCSとは独立
標準採用済みか いいえ。Round 1候補

NGCCとは　中国が量子時代を見据えて進める次世代暗号の標準化

NGCCは「Next-generation Commercial Cryptographic Algorithms Program」の略称です。

中国のInstitute of Commercial Cryptography Standards（ICCS）は2025年2月5日、量子コンピューターの脅威への対応と次世代商用暗号アルゴリズムの標準化を目的としてNGCCを開始しました。

募集対象は、公開鍵暗号、暗号学的ハッシュ、ブロック暗号です。公開鍵暗号では、デジタル署名、KEM、鍵交換などが候補として提出されています。

ICCSは2025年10月に公開鍵暗号とハッシュの正式な募集要項・評価基準を公開し、提出期限を2026年6月30日としました。

評価基準では、デジタル署名にはEUF-CMAまたはSUF-CMA、KEMにはIND-CCA2など、用途に応じた安全性を要求しています。最終候補は標準化の対象として検討されます。

今回のngcc.devの検証対象は、このRound 1候補です。

119候補のうち34候補にレポート、48件を公開

ngcc.devが掲載する119候補の内訳は次のとおりです。

分類 候補数 指摘が公開された候補 公開された指摘
デジタル署名 34 14 22
KEM 41 10 14
鍵交換 9 5 6
ハッシュ 35 5 6
合計 119 34 48

指摘は単に「脆弱性あり／なし」で分類されているわけではありません。

ngcc.devは裏付けの状態を次の4種類に分けています。

ステータス ngcc.devでの意味
Confirmed 問題と攻撃成立を確認
Probable 欠陥は確認したが具体的な攻撃までは導出していない
Lead 攻撃につながる可能性を示すヒューリスティックな手掛かり
Proof gap 安全性証明が主張を裏付けられない。単独では攻撃を意味しない

48件のうち44件がConfirmedです。

一方、MORNING-ScabbardとWeaverKEMはProbable、CHAMPの一部指摘はLead、VDOOの安全性証明に関する1件はProof gapとされています。

この区別をせず「48件すべてで暗号が破られた」と表現するのは正確ではありません。

Criticalは18件　実装ミスだけで暗号機能が成立しない例も

Criticalに分類された18件には、暗号理論そのものを破る高度な暗号解析だけでなく、リファレンス実装の単純な実装ミスによって安全性が失われるケースが複数含まれています。

代表的な例を整理します。

候補 分類 指摘 ngcc.devの評価
UVW 署名 検証APIが計算結果を無視し常に成功を返す Critical / Confirmed
Galas 署名 乱数生成器が適切に初期化されず秘密鍵を再現可能 Critical / Confirmed
VDOO 署名 公開実装から同一の署名鍵を再現可能 Critical / Confirmed
Aigis-Sig+ 署名 不正なヒント値でスタック書き込みが発生 Critical / Confirmed
Aigis-Enc+ KEM 暗号文拒否処理が機能せずIND-CCA安全性を破る Critical / Confirmed
CheetahKEM KEM 無効暗号文処理から共有秘密の一部が漏れる Critical / Confirmed
HEP-QC KEM 秘密鍵を公開実装から再現可能 Critical / Confirmed
LoongKEM KEM 無効暗号文処理から共有秘密が漏れる Critical / Confirmed
Polar-KEM KEM 公開鍵と暗号文だけで共有秘密を復元可能 Critical / Confirmed
AFS-KEX 鍵交換 セッションごとの一時鍵を再生成せず長期状態として再利用 Critical / Confirmed
CreTAKE 鍵交換 bits/bytesの取り違えで一時秘密が64ビットに低下 Critical / Confirmed
Eijen ハッシュ 複数パラメータで容易に衝突を生成可能 Critical / Confirmed
MasterCube ハッシュ 特定の境界条件で容易に衝突 Critical / Confirmed

これらは「量子コンピューターで将来破られる」という種類の問題ではなく、現行のリファレンス実装や設計条件そのものに対する指摘です。

UVWは「すべての署名を受理」、検証APIの戻り値に実装ミス

署名候補UVWでは、ngcc.devが「Every signature is accepted」と題したCriticalの問題を報告しています。

内部の検証処理自体は署名が正しいかどうかを計算していますが、APIラッパーがその結果を利用せず、最終的に常に成功を示す値を返していました。

このため、無効な署名、改ざんしたメッセージ、任意の長さを満たした署名データが有効な署名として扱われるとしています。

ngcc.devは全3パラメータセットでこの動作を確認し、「universal forgery」と位置付けています。

これは多変量暗号そのものへの新しい数学的攻撃ではなく、提出されたリファレンス実装のAPI処理に起因する問題です。

GalasとVDOOでは秘密鍵を再現可能

Galasでは、鍵生成に使う乱数生成器が公式APIから提供された乱数を使用せず、ゼロで初期化された状態から鍵を生成する問題が確認されています。

ngcc.devは異なるプロセスで鍵生成を行っても、同じ公開鍵と秘密鍵が生成されることを確認しました。

この場合、攻撃者は公開されている鍵生成実装を同じ初期状態から実行するだけで、被害側と同じ秘密署名鍵を生成できるとしています。

VDOOでも類似した問題が報告されています。

VDOOではAPI側の乱数生成器とは別のファイルローカルなDRNGが使われ、そのDRNGが初期化されていないため、異なるAPIシードを指定しても同じ鍵が生成されました。

いずれも暗号方式の数学的困難性以前に、乱数生成器の接続方法によって秘密鍵の秘匿性が失われる実装問題です。

Polar-KEMは公開鍵と暗号文だけで共有秘密を復元

KEM候補Polar-KEMでは、さらに直接的な問題が報告されています。

ngcc.devによると、提出されたソースコードには、公開鍵と暗号文からメッセージを復元し、正しい共有秘密を導出できる関数が含まれていました。

独立検証では、PolarKEM-128、256、512の3パラメータセットで、秘密鍵を渡さずに共有秘密を再現できたとしています。

レポートはこれを「complete public-key-only break」と表現しています。

ただし、ngcc.devは仕様書で定義されたPolar-KEMの構成そのものに同じ欠陥があるとはしていません。仕様では秘密にすべき変換が秘密鍵側に置かれていますが、提出された実装ではその変換を公開情報から再構成できる状態になっていたと説明しています。

つまり、設計そのものへの暗号解析というより、仕様とリファレンス実装の乖離による問題です。

Aigis-Enc+、CheetahKEM、LoongKEMではKEMの拒否処理に問題

複数のKEM候補では、無効な暗号文を受け取った場合の「implicit rejection」処理に問題が確認されています。

KEMでは、攻撃者が細工した暗号文から秘密情報を得られないよう、復号・再暗号化の検査に失敗した場合は本来の共有秘密とは別の値を返す処理が使われます。

Aigis-Enc+では、無効な暗号文を検知した後の置換処理が誤ったバッファへ書き込まれ、すでに出力された候補共有秘密が残る問題が確認されました。

CheetahKEMとLoongKEMでは、比較結果から生成する選択マスクが正しく正規化されず、無効暗号文への応答に本来の共有秘密の一部が残ると報告されています。

ngcc.devはいずれについても、提出されたIND-CCA安全性の主張を破ると評価しています。

CreTAKEではbitsとbytesの取り違え、一時秘密が64ビットに

鍵交換候補CreTAKEでは、実装上の単位の取り違えによって秘密値の強度が大幅に低下する問題が報告されています。

仕様上は64バイト、つまり512ビットの乱数を用意しています。

しかし、その値を疑似XOFへ渡す処理で「ビット数」を指定すべき引数に64を渡していたため、実際には先頭8バイト、64ビットしか入力に利用されていませんでした。

ngcc.devはこのパターンが23個のソースファイルに存在し、S2Sと呼ばれる6つのインスタンスでは、セッション鍵の秘密入力が実質64ビットになるとしています。

レポートでは、受動的に通信を観測した攻撃者が約2^64の候補をオフラインで探索できると評価しています。

EijenとMasterCubeでは容易なハッシュ衝突を確認

ハッシュ関数でもCriticalが確認されています。

Eijenでは、空文字列と「7ビットのゼロ」など異なる入力から同じハッシュ値が生成される事例が再現されています。

ngcc.devは原因を仕様上のハッシュ構造ではなく、リファレンス実装のパディング処理の不具合としています。

MasterCubeでも、メッセージ長が内部のrate境界付近にある場合、異なるビット長の入力が同じハッシュ値になる問題が確認されています。

暗号学的ハッシュでは、異なる入力から同じダイジェストを容易に作れない「衝突耐性」が基本要件の一つです。

いずれのレポートも、実装バグによってこの性質が失われると評価しています。

「512ビット安全性」を256ビット以下に制限する設計・実装も複数

Critical以外では、候補が主張する高い安全性レベルに対し、鍵生成シードやメッセージの事前ハッシュが短いため、実際にはより低い探索量で上限が決まるとの指摘が複数あります。

たとえばBiT、Origami、TSUOVなどでは、512ビットのメッセージ表現に対する一般的な衝突探索が約2^256で成立するため、512ビットの古典的偽造安全性をそのまま主張できないとしています。

COMPASS-KEMやHEP-QCでは、512ビット級のパラメータでも鍵生成元が256ビットに制限され、生成可能な公開鍵空間が最大2^256になるとの指摘があります。

これらは「2^256が現実的に総当たりできる」という意味ではありません。

問題となっているのは、候補が主張する512ビット級の安全性と、実際の構成から導かれる理論上の安全性上限が一致していない点です。

レポートはAI支援を明記、再現用ハーネスも公開

ngcc.devの各レポートには、Tampere UniversityのMarkku-Juhani O. Saarinen氏がクレジットされ、「with AI assistance」と明記されています。

Saarinen氏はTampere UniversityでProfessor of Practiceを務め、暗号解析、暗号プロトコル、サイドチャネル、暗号実装などを専門としています。

一方、今回の結果は査読済み論文ではありません。

ngcc.devは検証結果の再現性を確保するため、GitHubで「NGCC Round 1 reproduction harness」を公開しています。

このハーネスでは、提出者自身のリファレンスソースを利用し、ICCS公式APIと同じ方式で呼び出し、固定したビルド条件で共有ライブラリ化し、攻撃再現用テストや仕様・パラメータの静的監査を実行します。

リポジトリでは、提出物に含まれるMakefileやスクリプト、事前ビルド済みバイナリをそのまま実行せず、対象ソースを明示的に指定してビルドすると説明しています。

「No report」は「安全」を意味しない

ngcc.devの一覧では、多くの候補に「No report」と表示されています。

同サイトは、この表示について「このプロジェクトが候補に対する攻撃レポートを公開していない」という意味であり、安全性評価や「安全である」という主張ではないと明記しています。

119候補のうち34候補にレポートがあることから、「残り85候補は問題がなかった」「NGCC候補の約3割だけが脆弱」と結論付けることはできません。

検証の深さ、対象範囲、今後の追加調査によって件数は変わる可能性があります。また、ngcc.devの一覧自体も更新されているため、件数を引用する場合は更新日時を併記する必要があります。

NGCC候補は中国の正式標準ではない

今回の結果を「中国の暗号標準が破られた」と表現するのも正確ではありません。

NGCCは候補アルゴリズムを募集・評価し、最終候補を標準化の検討対象とするプログラムです。

今回対象となったのはRound 1候補であり、現時点で正式な国家標準・業界標準として採用されたアルゴリズムを一括して評価したものではありません。

ICCSの公式評価基準でも、安全性、性能、実装特性などを評価して候補を選定する方針が示されています。

第三者研究者がこの段階で設計・実装上の問題を公開することは、候補選定過程の一部として見る必要があります。

9月22日時点で、ICCS公式サイト上ではngcc.devの48件をまとめて扱った公式見解や、各候補提出者による修正版の一覧は確認できませんでした。

PQC移行では「標準化されたアルゴリズム」と実装を分けて確認

NGCCが始まった背景には、量子コンピューターによって現在の公開鍵暗号が将来破られる可能性があります。

一方、今回のレポートが示しているのは、耐量子性を持つ数学的問題を採用するだけでは十分ではないという点です。

候補の中には、乱数生成器の初期化ミス、戻り値の処理ミス、bitsとbytesの取り違え、パディング処理の不具合、無効暗号文の拒否処理の不備、仕様とリファレンス実装の不一致など、一般的なソフトウェア実装でも発生し得る問題が含まれています。

企業がPQCへ移行する場合も、「量子耐性のある方式を採用している」という説明だけで判断せず、標準化状況、実装ライブラリ、検証実績、更新体制を分けて確認する必要があります。

G7と日本政府のPQC移行方針については、以下の記事で整理しています。

関連：G7、量子時代に備えPQC移行を要請　「今収集・後で解読」リスク、日本政府も2035年までの移行目標

情報システム部門・セキュリティ担当者への示唆

今回の候補アルゴリズムを一般企業がそのまま本番環境で利用しているケースは限定的とみられます。現時点で企業側がNGCC候補を緊急停止するような状況ではありません。

PQC移行計画を進める企業では、次の点を確認できます。

  • 独自暗号や標準化前の候補アルゴリズムを本番用途に採用していないか
  • 製品ベンダーが採用するPQC方式の標準名と実装ライブラリを確認できるか
  • アルゴリズムの標準化状況と、具体的な実装のセキュリティ評価を分けて管理しているか
  • 暗号ライブラリを更新できるCrypto Agilityを確保しているか
  • 署名、KEM、TLS、VPN、証明書、HSMなど、PQC移行対象を棚卸ししているか
  • ベンダーがアルゴリズムやライブラリを変更した場合に追跡できるか
  • 「512ビット」「量子耐性」などの表記だけで安全性を判断せず、採用標準と評価資料を確認しているか

NGCCのRound 1評価は現在進行中です。続報では、ICCS側の公式評価、候補提出者による修正、ngcc.devの追加レポート、Round 1から次段階へ進む候補が確認対象になります。

出典

関連記事

Insecamとは？概要を解説Insecamとは 世界のWEBカメラ/監視カメラを閲覧できるサイト LockBit(ロックビット)とはサイバー攻撃集団 ロックビット(LockBit)とは？ 安洵信息技术有限公司（I-SOON）が中国政府向けにRATやサイバー攻撃ツールを提供し、「世論工作システム」として日本の新聞にも取り上げげられました。I-SOON 中国政府へサイバー攻撃 ツールを提供していた企業から内部リーク Hugging FaceでAIのバックドア 付き 機械学習モデルを確認 ChatGPTやGeminiなどの文章生成AIで拡散するマルウェア Morris II を研究者が発表 AIや生成AIの悪用事例やサイバー攻撃の事例を紹介AIや生成AIの悪用事例や事件を解説 富士通で個人情報漏洩の恐れ　マルウェア感染も富士通で個人情報漏洩の恐れ　マルウェア感染も 不正アクセスで「よどいこ！」から個人情報流出の可能性不正アクセスで「よどいこ！」から個人情報流出の可能性 モバイルファクトリーがSuishow 株式会社の現代表取締役へ訴訟提起 子会社化後に「NauNau」の個人情報漏洩疑惑が起因かモバイルファクトリーがSuishow 株式会社の現代表取締役へ訴訟提起 背景に「NauNau」のセキュリティ管理問題か？