共同執筆：Shane Kelly

米国商務省標準化技術研究所（NIST）がいくつかの耐量子コンピュータ暗号（PQC）アルゴリズムについてようやくリリースする最終仕様に関して、多くのことが言われていますが、1 つの重要な詳細が見落とされています。初期公開ドラフト（IPD）と NIST がリリースした最終バージョンとの違いは何でしょうか。

NIST PQC アルゴリズムの技術的な側面を取り上げ、何が変化したのかを調べましょう。また、新しい標準を導入する際の複雑さについても説明します。

最終仕様までの道のり

背景情報として、これまでの経緯を説明します。2017 年に、デジサートは米国商務省標準化技術研究所（NIST）と積極的に関わって、新しい暗号化標準の確立に取り組み始めました。この暗号化標準の目的は、量子コンピュータが従来の暗号化方式にもたらす脅威に対処することです。

デジサートは 2 つの点で関与しました。標準の開発プロセスへの貢献と、量子コンピュータがもたらす課題を研究者やメーカーと緊密に連携しながらより深く把握することにおいてです。

この過程においてデジサートは、業界リーダーや教育機関からなる多様なグループと連携して、これらの課題に正面から取り組んできました。デジサートのパートナーは、Thales 社（旧称 Gemalto 社）、Utimaco 社、Microsoft Research、ISARA Corporation、イリノイ大学アーバナ・シャンペーン校、ウォータールー大学などです。このコラボレーションのおかげで、耐量子コンピュータ暗号の理解と発展が進みました。こうしてデジサートは、新たに出現する技術的な脅威から未来を保護する上で最前線にいることができています。

PQC アルゴリズムの起源

2016 年に、NIST は PQC コンペティションを開始しました。これは、量子コンピュータが現在の公開鍵アルゴリズムを破る可能性があることを踏まえて、それに対処することを目的とした取り組みです。この取り組みから、候補となる 4 つのアルゴリズムが生み出されました。1 つは鍵カプセル化メカニズム（KEM）で、残りの 3 つは電子署名方式です。

2023 年 8 月 24 日に、NIST はこれらのうち 3 つのアルゴリズムについて初期ドラフトをリリースし、ほぼ 1 年後の 2024 年 8 月 13 日に最終ドラフトを公開しました。

コンペティションの過程において、選定された方式の名前は何度か変更されました。 

• 連邦情報処理標準（FIPS）203 は、当該仕様で ML-KEM と呼ばれており、元は CRYSTALS-Kyber という名前で提出されたモジュール格子ベース KEM です。
• FIPS 204 は、当該仕様で ML-DSA と呼ばれており、元は CRYSTALS-Dilithium という名前で提出されたモジュール格子ベースの電子署名アルゴリズムです。
• FIPS 205 は、当該仕様で SLH-DSA と呼ばれており、Sphincs+ として始まったステートレスなハッシュベースの署名方式です。
• FIPS-206 は、FN-DSA（Fast Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm）と呼ばれており、元は FALCON として提出されました。この候補の最終仕様は、最新のリリースにはまだ含まれていません。

初期公開ドラフト（IPD）と最終バージョンの比較

各アルゴリズムは、コンペティション全体を通じて一連の改訂を経てきました。これは、バイト順序の調整という小さな変更から、基盤となる格子構造に関する大きな変更まで多岐におよびます。更新が行われるたびに、暗号化コミュニティは最新バージョンに合わせて独自の実装を調整しました。

最終ドラフトのリリースも例外ではなく、各実装をもう一度更新する必要がありました。それがどのような作業であったか実感できるように、標準化された各アルゴリズムの 3 つの側面を IPD と最終バージョンの観点で比較しました。各仕様では、IPD と最終バージョンとの主要な違いを比較し、バージョンの相互運用性と、実装の変更の困難さを説明します。

ML-KEM/FIPS 203

違い

主な違いは、公開値 ⍴ とシークレットシード σ の生成方法にあります。改訂されたアプローチでは、各 ML-KEM バリアントに固有のパラメータ 𝐾 を組み込むドメインセパレータを使用して、これらの値が導出されます。パラメータ 𝐾 は ML-KEM バリアントごとに異なるため、生成プロセスにおける一意の識別子の役割を果たします。値 ⍴ と σ は、ハッシュ関数 𝐺 で生成されます。これらの値は以前、𝐺（𝑟𝑎𝑛𝑑𝑜𝑚 _ 𝑠𝑒𝑒𝑑）を呼び出すことで生成されていましたが、新しい方法では、𝐺（𝑟𝑎𝑛𝑑𝑜𝑚 _ 𝑠𝑒𝑒𝑑||𝐾）を呼び出します。これにより、生成プロセスにバリアント固有パラメータ 𝐾 が含められます。

相互運用性

IPD 仕様に従う ML-KEM の一時バージョンの実装と、最終ドラフトに従う ML-KEM バージョンの実装との間に相互運用性の問題はありません。その理由として、公開鍵の一部として送信される値 ⍴ が一定のままであること、カプセル化とカプセル解除の各プロセスが ⍴ の計算方法とは無関係なことが挙げられます。しかし、ML-KEM の静的バージョンでは相互運用性の問題が生じる可能性があります。特に、IPD バージョンで生成した秘密鍵を、FIPS 検証済みの ML-KEM の最終ドラフトバージョンにロードする場合に起こり得ます。この問題の発生を防げるかどうかは、ML-KEM のペア一貫性テストをどの程度綿密に行っているかにかかっています。このようなシナリオは考えられますが、実際に起こる可能性は低いので、通常は無視できます。

変更の困難さ

変更の影響はほとんどありません。

ML-DSA/FIPS 204

違い

HashML-DSA という新しい Hash then Sign 型バリアントが仕様に導入されました。ここで、Keygen 関数はそのままですが、新たな署名関数と検証関数の HashML-DSA.Sign（アルゴリズム 4）および HashML-DSA.Verify（アルゴリズム 5）が追加されました。また、この仕様では、個別のオブジェクト識別子（OID）を使用して ML-DSA と HashML-DSA を区別することも推奨しています。

さらに、署名関数と検証関数に、コンテキスト文字列という追加パラメータが導入されました。このコンテキスト文字列とその長さが、署名前にメッセージの先頭に追加されます。署名の検証時の関数 HintBitUnpack（アルゴリズム 21、IPD の旧アルゴリズム 15）には、正しくないヒントをチェックする機能が追加されました。このチェックは、バッファオーバーランを防ぐために再導入されました。

身元確認機関のチャレンジ生成に関して修正が加えられました。コミットメントハッシュの最初の 256 ビットだけを使用するのではなく、コミットメントハッシュ全体が SampleInBall 関数に渡されるようになりました。ML-DSA-44 は、コミットメントハッシュの出力が 256 ビットであるため影響を受けませんが、ML-DSA-65 と ML-DSA-87 には影響があります。

また、公開値 ⍴ とシークレットシード ⍴' および 𝐾 の生成に関して変更があります。これらの値はドメインセパレータを使って生成されるようになりました。このドメインセパレータは、各 ML-DSA バリアントに固有のパラメータ 𝐾 と 𝐼 を組み込みます。ハッシュ関数 𝐻 により、⍴、⍴'、および 𝐾 を得られます。以前は、𝐻（𝑟𝑎𝑛𝑑𝑜𝑚 _ 𝑠𝑒𝑒𝑑）を呼び出すことでこれらの値を生成していましたが、現在は、𝐻（𝑟𝑎𝑛𝑑𝑜𝑚 _ 𝑠𝑒𝑒𝑑∣∣𝐾∣∣𝐼）を呼び出して生成します。

最後に、署名者のコミットメントの計算に使用される関数 ExpandMask に変更が加えられたようですが、2 つのアルゴリズム（アルゴリズム 34、IPD の旧アルゴリズム 28）を調査したところ、違いは見られませんでした。

相互運用性

署名のコンテキスト文字列パラメータの導入により、相互運用性が完全に損なわれることになります。このパラメータをユーザーに公開しないとしても、下位互換性が失われていることには変わりありません。結果として、現在も将来においても、HashML-DSA は ML-DSA と互換性がないことになりました。

変更の困難さ

ML-DSA と HashML-DSA をプロトコルレベルで統合するのはかなりの課題です。2 つのアルゴリズムは互換性がなく、また Hash then Sign 型操作に HashML-DSA を使用するようユーザーは義務付けられていないため、それらの違いはプロトコルレベルでの困難な問題の発生につながります。

SLH-DSA/FIPS 205

違い

HashSLH-DSA という Hash then Sign 型バリアントが仕様に導入されました。ここで、Keygen 関数はそのままですが、新たな署名関数と検証関数の hash_slh_sign（アルゴリズム 23）および hash_slh_verify（アルゴリズム 25）が追加されました。仕様では、SLH-DSA と HashSLH-DSA の間に存在するオブジェクト識別子（OID）の違いについては何も言及していません。コンテキスト文字列という追加パラメータが、署名関数と検証関数に追加されました。このコンテキスト文字列とその長さが、署名前にメッセージの先頭に追加されます。

相互運用性

署名のコンテキスト文字列が追加されたため、SLH-DSA への下位互換性はありません。今後についても、HashSLH-DSA と SLH-DSA の互換性は確保されません。

変更の困難さ

Hash then Sign 型バリアントの追加は、ML-DSA の Hash then Sign 型バージョンの場合と同様の課題を生み出します。ML-DSA に関連する課題が解決された時点で、その解決策は直接 SLH-DSA に適用されます。その他の変更の影響はほとんどありません。

PQC の今後

Hash then Sign 型の署名と「純粋な」署名で採用されたドメイン区切りの署名という概念は、NIST の新しい方式であるため、慎重な考慮を要します。これにより、すべてのユーザーにとって最善の結果を得ることができます。

次に考慮すべきなのは、署名におけるコンテキスト文字列の扱い方です。業界基準の策定に向けて、暗号化コミュニティのエキスパートと協議を行えるかもしれません。このオプションが一般的に非公開になる可能性があり、その場合は、そのオプションを無視できます。

当社の暗号化システムにこれらの変更を実装するのは簡単なので、時間はかからないはずです。一方、テストベクターを作成して他の実装との互換性テストを実施するのは困難な課題となります。現時点では、比較対象とする他の実装が存在しないからです。

デジサートでは、当社のさまざまな製品に対して PQC 署名アルゴリズムを導入しており、DigiCert^® ONE PKI 管理プラットフォームでは、すでに 3 つのアルゴリズムをすべてサポートしています。DigiCert^® TrustCore SDK 開発者向けツールキットでは、ML-KEM/FIPS 203 に加え、PQC 署名のフルスイートをサポートしています。

デジタルトラストに関する最新情報

耐量子コンピュータ暗号、暗号化、PKI などのトピックについて詳細をご希望ですか？ 記事を見逃さないようにデジサートのブログを参照してください。