Internet Engineering Task Force (IETF) A. Banerjee
Request for Comments: 9958 T. Reddy.K
Category: Informational D. Schoinianakis
ISSN: 2070-1721 Nokia
T. Hollebeek
DigiCert
M. Ounsworth
Entrust
June 2026
The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), and it details the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms.
暗号関連量子コンピュータ (CRQC) の出現により、セキュリティを支える数学的前提がもはや成り立たなくなるため、現在導入されている最先端の従来の公開鍵アルゴリズムは時代遅れになるでしょう。これに対処するには、プロトコルとインフラストラクチャを、従来の攻撃と量子攻撃の両方に対抗するように設計されたポスト量子アルゴリズムに移行する必要があります。この文書では、エンジニアがポスト量子暗号 (PQC) を認識して理解する必要がある理由を説明し、既存のシステムに対する CRQC の影響と、ポスト量子アルゴリズムへの移行に伴う課題について詳しく説明します。以前の暗号アップデートとは異なり、この移行では、ポスト量子アルゴリズムの固有の特性により、プロトコルの大幅な再設計が必要になる可能性があります。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。IESG によって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではありません。RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9958.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9958 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology
3. Threat of CRQCs on Cryptography
3.1. Symmetric Cryptography
3.2. Asymmetric Cryptography
3.3. Quantum Side-Channel Attacks
4. Traditional Cryptographic Primitives That Could Be Replaced by
PQC
5. NIST PQC Algorithms
5.1. NIST Candidates Selected for Standardization
5.1.1. PQC Key Encapsulation Mechanisms (KEMs)
5.1.2. PQC Signatures
6. ISO Candidates Selected for Standardization
6.1. PQC Key Encapsulation Mechanisms (KEMs)
7. Timeline for Transition
8. PQC Categories
8.1. Lattice-Based Public Key Cryptography
8.2. Hash-Based Public Key Cryptography
8.3. Code-Based Public Key Cryptography
9. KEMs
9.1. Authenticated Key Exchange
9.2. Security Properties of KEMs
9.2.1. IND-CCA2
9.2.2. Binding
9.3. HPKE
10. PQC Signatures
10.1. Security Properties of PQC Signatures
10.1.1. EUF-CMA and SUF-CMA
10.2. Details of FN-DSA, ML-DSA, and SLH-DSA
10.3. Details of XMSS and LMS
10.3.1. LMS Key and Signature Sizes
10.4. Hash-then-Sign
11. NIST Recommendations for Security and Performance Trade-offs
12. Comparing PQC KEMs/Signatures against Traditional KEMs, Key
Exchanges, and Signatures
13. Post-Quantum and Traditional (PQ/T) Hybrid Schemes
13.1. PQ/T Hybrid Confidentiality
13.2. PQ/T Hybrid Authentication
13.3. Hybrid Cryptographic Algorithm Combinations:
Considerations and Approaches
13.3.1. Hybrid Cryptographic Combinations
13.3.2. Composite Keys in Hybrid Schemes
13.3.3. Key Reuse in Hybrid Schemes
13.3.4. Future Directions and Ongoing Research
14. Impact on Constrained Devices and Networks
15. Security Considerations
15.1. Cryptanalysis
15.2. Cryptographic Agility
15.3. Jurisdictional Fragmentation
15.4. Hybrid Key Exchange and Signatures: Bridging the Gap
Between PQ/T Cryptography
15.5. Caution: Ciphertext Commitment in KEM vs. DH
16. IANA Considerations
17. Further Reading and Resources
18. References
18.1. Normative References
18.2. Informative References
Acknowledgements
Authors' Addresses
Quantum computing is no longer just a theoretical concept in computational science and physics; it is now an active area of research with practical implications. Considerable research efforts and enormous corporate and government funding for the development of practical quantum computing systems are currently being invested. At the time this document is published, cryptographically relevant quantum computers (CRQCs) that can break widely used asymmetric algorithms (also known as public key algorithms) are not yet available. However, there is ongoing research and development in the field of quantum computing, with the goal of building more powerful and scalable quantum computers.
量子コンピューティングは、もはや計算科学や物理学における単なる理論上の概念ではありません。それは現在、実用的な意味を持つ活発な研究分野となっています。現在、実用的な量子コンピューティング システムの開発のために、多大な研究努力と企業および政府の巨額の資金が投資されています。この文書が公開された時点では、広く使用されている非対称アルゴリズム (公開鍵アルゴリズムとも呼ばれる) を解読できる暗号関連量子コンピューター (CRQC) はまだ利用可能ではありません。ただし、量子コンピューティングの分野では、より強力でスケーラブルな量子コンピューターを構築することを目的とした研究開発が継続しています。
One common myth is that quantum computers are faster than conventional CPUs and GPUs in all areas. This is not the case; much as GPUs outperform general-purpose CPUs only on specific types of problems, quantum computers also have a niche set of problems on which they excel. Unfortunately for cryptographers, integer factorization and discrete logarithms, the mathematical problems underpinning much of classical public key cryptography, happen to fall within the niche in which quantum computers are expected to excel. As quantum technology advances, there is the potential for future quantum computers to have a significant impact on current cryptographic systems. Predicting the date of emergence of a CRQC is a challenging task, and there is ongoing uncertainty regarding when they will become practically feasible [CRQCThreat].
一般的な通説の 1 つは、量子コンピューターはあらゆる分野で従来の CPU や GPU よりも高速であるというものです。これは当てはまりません。GPU が汎用 CPU よりも優れているのは特定の種類の問題においてのみであるのと同じように、量子コンピューターには得意とするニッチな一連の問題もあります。暗号学者にとって残念なことに、古典的な公開鍵暗号の多くを支えている数学的問題である整数因数分解と離散対数は、量子コンピューターが優れていると期待されるニッチ分野にたまたま当てはまります。量子技術が進歩するにつれて、将来の量子コンピュータが現在の暗号システムに大きな影響を与える可能性があります。CRQC の出現日を予測することは困難な作業であり、それがいつ実際に実現可能になるかについては依然として不確実性が存在します [CRQCTthreat]。
Extensive research has produced several post-quantum cryptographic algorithms that offer the potential to ensure cryptography's survival in the quantum computing era. However, transitioning to a post-quantum infrastructure is not a straightforward task, and there are numerous challenges to overcome. It requires a combination of engineering efforts, proactive assessment and evaluation of available technologies, and a careful approach to product development and deployment.
広範な研究により、量子コンピューティング時代における暗号の生き残りを保証する可能性をもたらすいくつかのポスト量子暗号アルゴリズムが生み出されました。ただし、ポスト量子インフラストラクチャへの移行は簡単な作業ではなく、克服すべき課題が数多くあります。それには、エンジニアリングの取り組み、利用可能なテクノロジーの事前の評価と評価、および製品の開発と展開に対する慎重なアプローチの組み合わせが必要です。
PQC is sometimes referred to as "quantum-proof", "quantum-safe", or "quantum-resistant". It is the development of cryptographic algorithms designed to secure communication and data in a world where quantum computers are powerful enough to break traditional cryptographic systems, such as RSA (Rivest-Shamir-Adleman) and ECC (Elliptic Curve Cryptography). PQC algorithms are intended to be resistant to attacks by quantum computers, which use quantum-mechanical phenomena to solve mathematical problems that are infeasible for classical computers.
PQC は、「耐量子性」、「耐量子性」、または「耐量子性」と呼ばれることもあります。これは、量子コンピューターが RSA (Rivest-Shamir-Adleman) や ECC (Elliptic Curve Cryptography) などの従来の暗号化システムを破るのに十分強力な世界において、通信とデータを保護するために設計された暗号化アルゴリズムの開発です。PQC アルゴリズムは、量子力学的現象を使用して古典的なコンピューターでは実行不可能な数学的問題を解決する量子コンピューターによる攻撃に耐性を持つことを目的としています。
As the threat of CRQCs draws nearer, engineers responsible for designing, maintaining, and securing cryptographic systems must prepare for the significant changes that the existence of CRQCs will bring. Engineers need to understand how to implement post-quantum algorithms in applications, how to evaluate the trade-offs between security and performance, and how to ensure backward compatibility with current systems where needed. This is not merely a one-for-one replacement of algorithms; in many cases, the shift to PQC will involve redesigning protocols and infrastructure to accommodate the significant differences in resource utilization and key sizes between traditional and PQC algorithms. Due to the wide-ranging nature of these impacts, discussions of protocol changes are integrated throughout this document rather than being confined to a single section.
CRQC の脅威が近づくにつれ、暗号システムの設計、保守、セキュリティ保護を担当するエンジニアは、CRQC の存在がもたらす重大な変化に備える必要があります。エンジニアは、アプリケーションにポスト量子アルゴリズムを実装する方法、セキュリティとパフォーマンスの間のトレードオフを評価する方法、必要に応じて現在のシステムとの下位互換性を確保する方法を理解する必要があります。これは、単にアルゴリズムを 1 対 1 で置き換えるだけではありません。多くの場合、PQC への移行には、従来のアルゴリズムと PQC アルゴリズムの間のリソース使用率とキー サイズの大きな違いに対応するためのプロトコルとインフラストラクチャの再設計が必要になります。これらの影響は広範囲にわたるため、プロトコルの変更に関する議論は 1 つのセクションに限定されるのではなく、このドキュメント全体に統合されています。
This document aims to provide general guidance to engineers working on cryptographic libraries, network security, and infrastructure development, where long-term security planning is crucial. The document covers topics such as selecting appropriate PQC algorithms and understanding the differences between PQC Key Encapsulation Mechanisms (KEMs) and traditional Diffie-Hellman (DH) and RSA-style key exchanges, and it provides insights into expected differences in keys, ciphertext, signature sizes, and processing times between PQC and traditional algorithms. Additionally, it discusses the potential threat to symmetric cryptography and hash functions from CRQCs.
このドキュメントは、長期的なセキュリティ計画が重要である暗号ライブラリ、ネットワーク セキュリティ、インフラストラクチャ開発に取り組むエンジニアに一般的なガイダンスを提供することを目的としています。このドキュメントでは、適切な PQC アルゴリズムの選択、PQC キー カプセル化メカニズム (KEM) と従来のディフィー ヘルマン (DH) および RSA スタイルのキー交換との違いの理解などのトピックが取り上げられており、PQC と従来のアルゴリズムの間で予想されるキー、暗号文、署名サイズ、処理時間の違いについての洞察が得られます。さらに、CRQC による対称暗号化とハッシュ関数に対する潜在的な脅威についても説明します。
It is important to remember that asymmetric algorithms (also known as public key algorithms) are largely used for secure communications between organizations or endpoints that may not have previously interacted, so a significant amount of coordination between organizations, and within and between ecosystems, needs to be taken into account. Such transitions are some of the most complicated in the tech industry and will require staged migrations in which upgraded agents need to coexist and communicate with non-upgraded agents at a scale never before undertaken.
非対称アルゴリズム (公開鍵アルゴリズムとも呼ばれる) は主に、これまで対話したことのない組織またはエンドポイント間の安全な通信に使用されるため、組織間、およびエコシステム内およびエコシステム間でのかなりの量の調整を考慮する必要があることを覚えておくことが重要です。このような移行はテクノロジー業界で最も複雑なものの 1 つであり、アップグレードされたエージェントがアップグレードされていないエージェントと共存し、これまでにない規模で通信する必要がある段階的な移行が必要になります。
The National Security Agency (NSA) of the United States released an article on future PQC algorithm requirements for US national security systems [CNSA2-0] based on the need to protect against deployments of CRQCs in the future. The German Federal Office for Information Security (BSI) has also released a PQC migration and recommendations document [BSI-PQC] that largely aligns with United States National Institute of Standards and Technology (NIST) and NSA guidance but differs in aspects such as specific PQC algorithm profiles.
米国国家安全保障局 (NSA) は、将来の CRQC の展開に対する保護の必要性に基づいて、米国国家安全保障システムの将来の PQC アルゴリズム要件に関する記事 [CNSA2-0] を発表しました。ドイツ連邦情報セキュリティ局 (BSI) も、PQC の移行と推奨事項に関する文書 [BSI-PQC] をリリースしました。この文書は、米国国立標準技術研究所 (NIST) および NSA のガイダンスとほぼ一致していますが、特定の PQC アルゴリズム プロファイルなどの点で異なります。
CRQCs pose a threat to both symmetric and asymmetric cryptographic schemes. However, the threat to asymmetric cryptography is significantly greater due to Shor's algorithm [Shors], which can break widely used public key schemes like RSA and ECC. Symmetric cryptography and hash functions face a lower risk from Grover's algorithm [Grovers], although the impact is less severe and can typically be mitigated by doubling key and digest lengths where the risk applies. It is crucial for the reader to understand that when "PQC" is mentioned in the document, it means asymmetric cryptography (or public key cryptography) and not any symmetric algorithms based on stream ciphers, block ciphers, hash functions, Message Authentication Codes (MACs), etc., which are less vulnerable to quantum computers. This document does not cover topics such as when traditional algorithms might become vulnerable (for that, see documents such as [QC-DNS] and others).
CRQC は、対称暗号化スキームと非対称暗号化スキームの両方に脅威をもたらします。ただし、RSA や ECC などの広く使用されている公開鍵スキームを破る可能性がある Shor のアルゴリズム [Shors] により、非対称暗号化に対する脅威は大幅に大きくなります。対称暗号化とハッシュ関数は、Grover のアルゴリズム [Grovers] によるリスクが低くなりますが、影響はそれほど深刻ではなく、通常、リスクが適用されるキーとダイジェストの長さを 2 倍にすることで軽減できます。文書内で「PQC」について言及されている場合、それは非対称暗号化 (または公開キー暗号化) を意味し、量子コンピューターに対して脆弱性が低いストリーム暗号、ブロック暗号、ハッシュ関数、メッセージ認証コード (MAC) などに基づく対称アルゴリズムではないことを読者が理解することが重要です。この文書では、従来のアルゴリズムがいつ脆弱になる可能性があるかなどのトピックについては取り上げていません (これについては、[QC-DNS] などの文書を参照してください)。
This document does not cover unrelated technologies like quantum key distribution (QKD) or quantum key generation, which use quantum hardware to exploit quantum effects to protect communications and generate keys, respectively. PQC is based on conventional math (not on quantum mechanics) and software, and it can be run on any general-purpose computer.
このドキュメントでは、量子ハードウェアを使用して量子効果を利用してそれぞれ通信を保護し、鍵を生成する、量子鍵配布 (QKD) や量子鍵生成などの無関係なテクノロジについては説明しません。PQC は従来の数学 (量子力学ではない) とソフトウェアに基づいており、汎用コンピューター上で実行できます。
This document does not go into the deep mathematics or technical specification of the PQC algorithms but rather provides an overview to engineers on the current threat landscape and the relevant algorithms designed to help prevent those threats. Also, the cryptographic and algorithmic guidance given in this document should be taken as non-authoritative if it conflicts with emerging and evolving guidance from the IRTF's Crypto Forum Research Group (CFRG).
この文書は、PQC アルゴリズムの数学的仕様や技術仕様については詳しく説明するものではなく、現在の脅威の状況と、それらの脅威を防ぐために設計された関連アルゴリズムについてエンジニアに概要を提供します。また、この文書に記載されている暗号およびアルゴリズムに関するガイダンスが、IRTF の暗号フォーラム研究グループ (CFRG) から新たに出現し進化しつつあるガイダンスと矛盾する場合は、権威がないとみなされる必要があります。
Quantum computer:
量子コンピューター:
A computer that performs computations using quantum-mechanical phenomena such as superposition and entanglement.
重ね合わせやもつれなどの量子力学的現象を利用して計算を実行するコンピューター。
Physical qubit:
物理量子ビット:
The basic physical unit in a quantum computer, which is prone to noise and errors.
量子コンピューターの基本的な物理単位。ノイズやエラーが発生しやすい。
Logical qubit:
論理量子ビット:
A fault-tolerant qubit constructed from multiple physical qubits using quantum error correction; it is the effective unit for reliable quantum computation.
量子誤り訂正を使用して複数の物理量子ビットから構築されたフォールトトレラント量子ビット。これは、信頼性の高い量子計算のための効果的なユニットです。
Post-Quantum Cryptography (PQC):
ポスト量子暗号 (PQC):
Cryptographic algorithms designed to be secure against quantum and classical attacks.
量子攻撃および古典的攻撃に対して安全になるように設計された暗号アルゴリズム。
Cryptographically Relevant Quantum Computer (CRQC):
暗号関連量子コンピューター (CRQC):
A quantum computer with sufficient logical qubits to break traditional asymmetric cryptographic algorithms (e.g., RSA or ECC) within a practical timeframe.
従来の非対称暗号アルゴリズム (RSA や ECC など) を実用的な時間枠内で突破するのに十分な論理量子ビットを備えた量子コンピューター。
Public Key Cryptography (also called Asymmetric Cryptography):
公開キー暗号化 (非対称暗号化とも呼ばれます):
A class of cryptographic algorithms in which separate keys are used for encryption and decryption or for signing and verification. Throughout this document, the terms Public Key Cryptography and Asymmetric Cryptography are used interchangeably.
暗号化と復号化、または署名と検証に個別のキーが使用される暗号化アルゴリズムのクラス。このドキュメント全体を通じて、公開キー暗号化と非対称暗号化という用語は同じ意味で使用されます。
There is ongoing discussion about whether to use the term "post-quantum", "quantum ready", "quantum resistant", or "quantum secure" to describe algorithms that resist CRQCs, and a consensus has not yet been reached. NIST has coined the term "post-quantum" to refer to the algorithms that participated in its competition-like selection process; in this context, the term can be interpreted to mean "the set of algorithms that are designed to still be relevant after quantum computers exist" and not a statement about their security. "Quantum resistant" or "quantum secure" is obviously the goal of these algorithms; however, some people have raised concerns that labeling a class of algorithms as "quantum resistant" or "quantum secure" could lead to confusion if one or more of those algorithms are later found to be insecure or to not resist quantum computers as much as theory predicted. "Quantum ready" is often used to refer to a solution -- device, appliance, or software stack -- that has reached maturity with regard to integration of these new cryptographic algorithms. That said, the authors recognize that there is great variability in how these terms are used. This document uses these terms interchangeably to refer to such algorithms.
CRQC に対抗するアルゴリズムを説明するために「ポスト量子」、「量子対応」、「耐量子」、または「量子安全」のいずれの用語を使用するかについては議論が続いており、まだ合意には達していません。NIST は、競争のような選択プロセスに参加したアルゴリズムを指すために「ポスト量子」という用語を作りました。この文脈では、この用語は「量子コンピューターが存在した後も関連性を保つように設計された一連のアルゴリズム」を意味し、そのセキュリティに関する声明ではないと解釈できます。「量子耐性」または「量子安全」がこれらのアルゴリズムの目標であることは明らかです。しかし、一部の人々は、アルゴリズムのクラスに「量子耐性」または「量子安全」というラベルを付けると、後でそれらのアルゴリズムの 1 つまたは複数が安全ではない、または理論が予測したほど量子コンピューターに耐性がないことが判明した場合に混乱を招く可能性があると懸念を表明しています。「量子対応」は、これらの新しい暗号アルゴリズムの統合に関して成熟度に達したソリューション (デバイス、アプライアンス、またはソフトウェア スタック) を指すのによく使用されます。とはいえ、著者らは、これらの用語の使用方法には大きなばらつきがあることを認識しています。このドキュメントでは、そのようなアルゴリズムを指すためにこれらの用語を同じ意味で使用します。
In this document, the terms "current", "state-of-the-art", and "ongoing" refer to work, research, investigations, deployments, or developments that are applicable at the time of publication.
この文書では、「現在」、「最先端」、および「進行中」という用語は、発行時点で適用される作業、研究、調査、展開、または開発を指します。
When considering the security risks associated with the ability of a quantum computer to attack traditional cryptography, it is important to distinguish between the impact on symmetric algorithms and public key ones. Dr. Peter Shor and Dr. Lov Grover developed two algorithms that changed the way the world thinks of security under the presence of a CRQC.
従来の暗号を攻撃する量子コンピューターの能力に関連するセキュリティ リスクを考慮する場合、対称アルゴリズムへの影響と公開鍵アルゴリズムへの影響を区別することが重要です。Peter Shor 博士と Lov Grover 博士は、CRQC の存在下でのセキュリティに対する世界の考え方を変える 2 つのアルゴリズムを開発しました。
Quantum computers are, by their nature, hybrids of classical and quantum computational units. For example, Shor's algorithm consists of a combination of quantum and classical computational steps. Thus, the term "quantum adversary" should be thought of as "quantum-enhanced adversary", meaning they have access to both classical and quantum computational techniques.
量子コンピューターは、その性質上、古典的な計算ユニットと量子計算ユニットのハイブリッドです。たとえば、Shor のアルゴリズムは、量子計算ステップと古典的な計算ステップの組み合わせで構成されています。したがって、「量子攻撃者」という用語は、「量子強化攻撃者」、つまり古典的計算技術と量子計算技術の両方にアクセスできることを意味すると考えるべきです。
Although large-scale quantum computers do not yet exist to experiment on, the theoretical properties of quantum computation are very well understood. This allows engineers and researchers to reason about the upper limits of quantum-enhanced computation and to design cryptographic algorithms that are resistant to any conceivable form of quantum cryptanalysis.
大規模な量子コンピューターはまだ実験できるものではありませんが、量子コンピューターの理論的特性はよく理解されています。これにより、エンジニアや研究者は、量子強化計算の上限について推論し、考えられるあらゆる形式の量子暗号解析に耐性のある暗号アルゴリズムを設計することができます。
For unstructured data such as symmetric encrypted data or cryptographic hashes, although CRQCs can search for specific solutions across all possible input combinations (e.g., Grover's algorithm), no quantum algorithm is known to break the underlying security properties of these classes of algorithms. Symmetric-key cryptography, which includes keyed primitives such as block ciphers (e.g., AES) and message authentication mechanisms (e.g., HMAC-SHA256), relies on secret keys shared between the sender and receiver and remains secure even in a post-quantum world. Symmetric cryptography also includes hash functions (e.g., SHA-256) that are used for secure message digesting without any shared key material. Hashed Message Authentication Code (HMAC) is a specific construction that utilizes a cryptographic hash function and a secret key shared between the sender and receiver to produce a message authentication code.
対称暗号化データや暗号ハッシュなどの非構造化データの場合、CRQC は考えられるすべての入力の組み合わせ (グローバーのアルゴリズムなど) にわたって特定の解決策を検索できますが、これらのクラスのアルゴリズムの基礎となるセキュリティ特性を破る量子アルゴリズムは知られていません。ブロック暗号 (AES など) やメッセージ認証メカニズム (HMAC-SHA256 など) などのキー付きプリミティブを含む対称キー暗号化は、送信者と受信者の間で共有される秘密鍵に依存し、ポスト量子の世界でも安全性を保ちます。対称暗号化には、共有キー素材を使用せずに安全なメッセージ ダイジェストに使用されるハッシュ関数 (SHA-256 など) も含まれます。ハッシュ メッセージ認証コード (HMAC) は、暗号化ハッシュ関数と送信者と受信者の間で共有される秘密キーを利用してメッセージ認証コードを生成する特別な構造です。
Grover's algorithm is a quantum search algorithm that provides a theoretical quadratic speedup for searching an unstructured database, compared to traditional search algorithms. This has led to the common misconception that symmetric key lengths need to be doubled for quantum security. When you consider the mapping of hash values to their corresponding hash inputs (also known as pre-image) or of ciphertext blocks to the corresponding plaintext blocks as an unstructured database, then Grover's algorithm theoretically requires doubling the key sizes of the symmetric algorithms that are currently deployed at the time of publication to counter the quadratic speedup and maintain the current security level. This is because Grover's algorithm reduces the amount of operations to break 128-bit symmetric cryptography to 2^64 quantum operations, which might sound computationally feasible. However, quantum operations are fundamentally different from classical ones, as 2^64 classical operations can be efficiently parallelized but 2^64 quantum operations must be performed serially, making them infeasible on practical quantum computers.
Grover のアルゴリズムは、従来の検索アルゴリズムと比較して、非構造化データベースの検索を理論的に 2 次的に高速化する量子検索アルゴリズムです。このため、量子セキュリティのために対称鍵の長さを 2 倍にする必要があるという一般的な誤解が生じています。非構造化データベースとして、ハッシュ値から対応するハッシュ入力 (プリイメージとも呼ばれます) へのマッピング、または暗号文ブロックから対応する平文ブロックへのマッピングを考慮すると、グローバーのアルゴリズムでは、理論的には、二次高速化に対抗し、現在のセキュリティ レベルを維持するために、公開時に現在展開されている対称アルゴリズムのキー サイズを 2 倍にする必要があります。これは、Grover のアルゴリズムにより、128 ビット対称暗号を解読するための演算量が 2^64 量子演算に削減され、計算上実現可能であると思われるためです。ただし、量子演算は古典演算とは根本的に異なります。2^64 の古典演算は効率的に並列化できますが、2^64 量子演算は逐次的に実行する必要があり、実際の量子コンピューターでは実行不可能です。
Grover's algorithm is highly non-parallelizable and even if one deploys 2^c computational units in parallel to brute-force a key using Grover's algorithm, it will complete in time proportional to 2^((128-c)/2), or, put simply, using 256 quantum computers will only reduce runtime by a factor of 16, 1024 quantum computers will only reduce runtime by a factor of 32, and so forth (see [NIST] and [Cloudflare]). Due to this inherent limitation, the general expert consensus is that AES-128 remains secure in practice and key sizes do not necessarily need to be doubled.
グローバーのアルゴリズムは非常に非並列性が高く、グローバーのアルゴリズムを使用してキーの総当たり攻撃を実行するために 2^c 個の計算ユニットを並列に配置したとしても、2^((128-c)/2) に比例する時間内に完了します。つまり、簡単に言うと、256 台の量子コンピューターを使用しても実行時間は 16 分の 1 しか短縮されず、1024 台の量子コンピューターを使用しても実行時間は 32 分の 1 しか短縮されません。など ([NIST] および [Cloudflare] を参照)。この固有の制限により、AES-128 は実際には安全であり、キー サイズを必ずしも 2 倍にする必要はないというのが専門家の一般的な意見です。
It would be natural to ask whether future research will develop a superior algorithm that could outperform Grover's algorithm in the general case. However, Christof Zalka has shown that Grover's algorithm achieves the best possible complexity for this type of search, meaning no significantly faster quantum approach is expected [Grover-Search].
将来の研究で、一般的なケースでグローバーのアルゴリズムを上回る優れたアルゴリズムが開発されるかどうか疑問に思うのは自然なことでしょう。しかし、Christof Zalka は、Grover のアルゴリズムがこのタイプの検索で可能な限り最高の複雑さを実現していることを示しました。これは、大幅に高速な量子アプローチは期待できないことを意味します [Grover-Search]。
Finally, in their evaluation criteria for PQC, NIST is assessing the security levels of proposed post-quantum algorithms by comparing them against the equivalent traditional and quantum security of AES-128, AES-192, and AES-256. This indicates that NIST is confident in the stable security properties of AES, even in the presence of both traditional and quantum attacks. As a result, 128-bit algorithms can be considered quantum-safe for the foreseeable future. However, for compliance purposes, some organizations, such as the French National Agency for the Security of Information Systems (ANSSI) [ANSSI] and the National Security Agency (NSA) (CNSA 2.0) [CNSA2-0], recommend the use of AES-256.
最後に、NIST は、PQC の評価基準において、提案されているポスト量子アルゴリズムのセキュリティ レベルを、AES-128、AES-192、および AES-256 の同等の従来の量子セキュリティと比較することによって評価しています。これは、NIST が、従来の攻撃と量子攻撃の両方が存在する場合でも、AES の安定したセキュリティ特性に自信を持っていることを示しています。その結果、128 ビット アルゴリズムは、当面は量子安全であると考えられます。ただし、コンプライアンスの目的から、フランス情報システムセキュリティ庁 (ANSSI) [ANSSI] や国家安全保障局 (NSA) (CNSA 2.0) [CNSA2-0] などの一部の組織は、AES-256 の使用を推奨しています。
"Shor's algorithm" efficiently solves the integer factorization problem (and the related discrete logarithm problem), which underpin the foundations of the vast majority of public key cryptography that the world uses today. This implies that, if a CRQC is developed, today's public key algorithms (e.g., RSA, Diffie-Hellman, and ECC, as well as less commonly used variants such as ElGamal [RFC6090] and Schnorr signatures [RFC8235]) and protocols would need to be replaced by algorithms and protocols that can offer cryptanalytic resistance against CRQCs. Note that Shor's algorithm cannot run solely on a classical computer; it requires a CRQC.
「ショールのアルゴリズム」は、今日世界中で使用されている公開鍵暗号の大部分の基礎を支える整数因数分解問題 (および関連する離散対数問題) を効率的に解決します。これは、CRQC が開発された場合、今日の公開鍵アルゴリズム (RSA、Diffie-Hellman、ECC、および ElGamal [RFC6090] や Schnorr 署名 [RFC8235] などのあまり一般的に使用されていないバリアント) とプロトコルを、CRQC に対する暗号解読耐性を提供できるアルゴリズムとプロトコルに置き換える必要があることを意味します。Shor のアルゴリズムは古典的なコンピューターだけでは実行できないことに注意してください。CRQC が必要です。
For example, studies show that, if a CRQC existed, it could break RSA-2048 in hours or even seconds depending on assumptions about error correction [RSAShor] [RSA8HRS] [RSA10SC]. While such machines are purely theoretical at the time of writing, this illustrates the eventual vulnerability of RSA to CRQCs.
たとえば、研究によると、CRQC が存在すると、エラー修正に関する仮定によっては、数時間または数秒で RSA-2048 が破壊される可能性があります [RSAShor] [RSA8HRS] [RSA10SC]。このようなマシンは執筆時点では純粋に理論上のものですが、これは CRQC に対する RSA の最終的な脆弱性を示しています。
For structured data such as public keys and signatures, CRQCs can fully solve the underlying hard problems used in traditional cryptography (see Shor's algorithm). Because an increase in the size of the key pair would not provide a secure solution (short of RSA keys that are many gigabytes in size [PQRSA]), a complete replacement of the algorithm is needed. Therefore, post-quantum public key cryptography must rely on problems that are different from the ones used in traditional public key cryptography (i.e., the integer factorization problem, the finite-field discrete logarithm problem, and the elliptic-curve discrete logarithm problem).
公開キーや署名などの構造化データの場合、CRQC は従来の暗号化で使用される根本的な困難な問題を完全に解決できます (Shor のアルゴリズムを参照)。キー ペアのサイズを増やすと安全なソリューションが提供されないため (サイズが数ギガバイトになる RSA キー [PQRSA] が不足します)、アルゴリズムを完全に置き換える必要があります。したがって、ポスト量子公開鍵暗号は、従来の公開鍵暗号で使用される問題とは異なる問題 (つまり、整数因数分解問題、有限体離散対数問題、楕円曲線離散対数問題) に依存する必要があります。
Cryptographic side-channel attacks exploit physical implementations (such as timing, power consumption, or electromagnetic leakage) to recover secret keys.
暗号化サイドチャネル攻撃は、物理的な実装 (タイミング、電力消費、電磁漏洩など) を悪用して秘密鍵を回復します。
The field of cryptographic side-channel attacks potentially stands to gain a boost in attacker power once cryptanalytic techniques can be enhanced with quantum computation techniques [QuantSide]. While a full discussion of quantum side-channel techniques is beyond the scope of this document, implementers of cryptographic hardware should be aware that current best practices for side-channel resistance may not be sufficient against quantum adversaries.
暗号解析技術を量子計算技術 [QuantSide] で強化できれば、暗号サイドチャネル攻撃の分野では攻撃力がさらに高まる可能性があります。量子サイドチャネル技術の詳細な説明はこのドキュメントの範囲を超えていますが、暗号ハードウェアの実装者は、サイドチャネル耐性に関する現在のベスト プラクティスが量子攻撃者に対して十分でない可能性があることを認識する必要があります。
Any asymmetric cryptographic algorithm based on integer factorization, finite field discrete logarithms, or elliptic-curve discrete logarithms will be vulnerable to attacks using Shor's algorithm on a CRQC. This document focuses on the principal functions of asymmetric cryptography:
整数因数分解、有限体離散対数、または楕円曲線離散対数に基づく非対称暗号アルゴリズムは、CRQC でショールのアルゴリズムを使用した攻撃に対して脆弱になります。このドキュメントでは、非対称暗号化の主な機能に焦点を当てます。
Key agreement and key transport:
鍵の合意と鍵の転送:
Key agreement schemes, typically referred to as Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH), as well as key transport, typically using RSA encryption, are used to establish a shared cryptographic key for secure communication. They are one of the mechanisms that can be replaced by PQC, as they are based on existing public key cryptography and are therefore vulnerable to Shor's algorithm. A CRQC can employ Shor's algorithm to efficiently find the prime factors of a large public key (in the case of RSA), which, in turn, can be exploited to derive the private key. In the case of DH, a CRQC has the potential to calculate the discrete logarithm of the (short- or long-term) DH public key. This, in turn, would reveal the secret required to derive the symmetric encryption key.
通常、Diffie-Hellman (DH) または Elliptic Curve Diffie-Hellman (ECDH) と呼ばれる鍵合意スキームと、通常 RSA 暗号化を使用する鍵転送は、安全な通信のための共有暗号鍵を確立するために使用されます。これらは既存の公開キー暗号化に基づいているため、Shor のアルゴリズムに対して脆弱であるため、PQC に置き換えることができるメカニズムの 1 つです。CRQC は、Shor のアルゴリズムを使用して、大きな公開鍵 (RSA の場合) の素因数を効率的に見つけることができ、これを利用して秘密鍵を導出できます。DH の場合、CRQC は (短期または長期の) DH 公開キーの離散対数を計算できる可能性があります。これにより、対称暗号化キーを導出するために必要な秘密が明らかになります。
Digital signatures:
デジタル署名:
Digital signature schemes are used to authenticate the identity of a sender, detect unauthorized modifications to data, and underpin trust in a system. Similar to key agreement, signatures also depend on a public-private key pair based on the same mathematics as for key agreement and key transport. Because of this, a break in existing public key cryptography will also affect traditional digital signatures, hence the importance of developing post-quantum digital signatures.
デジタル署名スキームは、送信者の身元を認証し、データへの不正な変更を検出し、システムの信頼を裏付けるために使用されます。鍵の合意と同様に、署名も鍵の合意や鍵の転送と同じ数学に基づく公開鍵と秘密鍵のペアに依存します。このため、既存の公開キー暗号化の破壊は従来のデジタル署名にも影響を与えるため、ポスト量子デジタル署名の開発が重要になります。
Boneh-Boyen-Shacham (BBS) signatures:
Boneh-Boyen-Shacham (BBS) の署名:
BBS signatures are a privacy-preserving signature scheme that offers zero-knowledge proof-like properties by allowing selective disclosure of specific signed attributes without revealing the entire set of signed data. The security of BBS signatures relies on the hardness of the discrete logarithm problem, making them vulnerable to Shor's algorithm. A CRQC can break the data authenticity security property of BBS but not the data confidentiality (Section 6.9 of [BBS-SIG-SCHEME]).
BBS 署名は、署名されたデータのセット全体を明らかにすることなく、特定の署名された属性を選択的に開示できるようにすることで、ゼロ知識証明のような特性を提供する、プライバシーを保護する署名スキームです。BBS 署名のセキュリティは離散対数問題の難易度に依存しているため、Shor のアルゴリズムに対して脆弱になります。CRQC は BBS のデータの信頼性セキュリティ プロパティを破ることはできますが、データの機密性は破ることはできません ([BBS-SIG-SCHEME] のセクション 6.9)。
Content encryption:
コンテンツの暗号化:
Content encryption typically refers to the encryption of the data using symmetric key algorithms, such as AES, to ensure confidentiality. The threat to symmetric cryptography is discussed in Section 3.1.
コンテンツ暗号化とは通常、機密性を確保するために AES などの対称キー アルゴリズムを使用したデータの暗号化を指します。対称暗号に対する脅威については、セクション 3.1 で説明します。
At the time of writing, NIST has standardized three PQC algorithms, with more expected to be standardized in the future (see [NISTFINAL]). These algorithms are not necessarily drop-in replacements for traditional asymmetric cryptographic algorithms. For instance, RSA [RSA] and ECC [RFC6090] can be used as both a KEM and a signature scheme, whereas there is currently no post-quantum algorithm that can perform both functions. When upgrading protocols, it is important to replace the existing use of traditional algorithms with either a PQC KEM or a PQC signature method, depending on how the traditional algorithm was previously being used. Additionally, KEMs, as described in Section 9, present a different API than either key agreement or key transport primitives. As a result, they may require protocol-level or application-level changes in order to be incorporated.
この記事の執筆時点で、NIST は 3 つの PQC アルゴリズムを標準化していますが、将来的にはさらに多くのアルゴリズムが標準化されることが予想されます ([NISTFINAL] を参照)。これらのアルゴリズムは、必ずしも従来の非対称暗号アルゴリズムをそのまま置き換えるものではありません。たとえば、RSA [RSA] と ECC [RFC6090] は KEM と署名スキームの両方として使用できますが、現在、両方の機能を実行できるポスト量子アルゴリズムはありません。プロトコルをアップグレードする場合は、従来のアルゴリズムが以前どのように使用されていたかに応じて、従来のアルゴリズムの既存の使用を PQC KEM または PQC 署名方式に置き換えることが重要です。さらに、セクション 9 で説明されているように、KEM は、鍵合意または鍵トランスポートプリミティブとは異なる API を提供します。その結果、それらを組み込むには、プロトコル レベルまたはアプリケーション レベルの変更が必要になる場合があります。
ML-KEM:
ML-KEM:
Module-Lattice-Based Key-Encapsulation Mechanism. See FIPS 203 [ML-KEM].
モジュールラティスベースのキーカプセル化メカニズム。FIPS 203 [ML-KEM] を参照してください。
HQC:
HQC:
Hamming Quasi-Cyclic. See [HQC]. The coding algorithm based on the hardness of the syndrome decoding problem for quasi-cyclic concatenated Reed-Muller and Reed-Solomon (RMRS) codes in the Hamming metric. Reed-Muller (RM) codes are a class of block error-correcting codes commonly used in wireless and deep-space communications, while Reed-Solomon (RS) codes are widely used to detect and correct multiple-bit errors. HQC has been selected as part of the NIST post-quantum cryptography project but has not yet been standardized.
ハミング準巡回。[HQC]を参照してください。ハミングメトリックにおける準巡回連結リードミュラーおよびリードソロモン (RMRS) コードのシンドローム復号化問題の難易度に基づくコーディング アルゴリズム。リードマラー (RM) コードは、無線通信や深宇宙通信で一般的に使用されるブロック誤り訂正コードの一種であり、一方、リードソロモン (RS) コードは、複数ビットのエラーの検出と訂正に広く使用されています。HQC は NIST ポスト量子暗号化プロジェクトの一部として選択されましたが、まだ標準化されていません。
ML-DSA:
ML-DSA:
Module-Lattice-Based Digital Signature Algorithm. See FIPS 204 [ML-DSA].
モジュール格子ベースのデジタル署名アルゴリズム。FIPS 204 [ML-DSA] を参照してください。
SLH-DSA:
SLH-DSA:
Stateless Hash-Based Digital Signature Algorithm. See FIPS 205 [SLH-DSA].
ステートレスなハッシュベースのデジタル署名アルゴリズム。FIPS 205 [SLH-DSA] を参照してください。
FN-DSA:
FN-DSA:
Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm. See [FN-DSA]; note that NIST has named this algorithm "FN-DSA" and assigned "FIPS 206" for its specification, but at the time of this document's publication, it has not yet been released.
NTRU格子ベースのデジタル署名アルゴリズムによる高速フーリエ変換。[FN-DSA] を参照。NIST はこのアルゴリズムを「FN-DSA」と名付け、その仕様に「FIPS 206」を割り当てていますが、この文書の発行時点ではまだリリースされていないことに注意してください。
For more information about these, see Sections 8.1, 8.2, and 10.2.
これらの詳細については、セクション 8.1、8.2、および 10.2 を参照してください。
At the time of writing, ISO has selected three PQC KEM algorithms as candidates for standardization; these are mentioned in the following subsection.
この記事の執筆時点で、ISO は 3 つの PQC KEM アルゴリズムを標準化の候補として選択しました。これらについては次のサブセクションで説明します。
FrodoKEM:
フロドKEM:
KEM based on the hardness of learning with errors in algebraically unstructured lattices. See [FrodoKEM].
KEM は、代数的に非構造化された格子のエラーによる学習の難しさに基づいています。「FrodoKEM」を参照してください。
ClassicMcEliece:
古典的なマクリース:
KEM based on the hardness of syndrome decoding of Goppa codes. Goppa codes are a class of error-correcting codes that can correct a certain number of errors in a transmitted message. The decoding problem involves recovering the original message from the received noisy codeword. See [ClassicMcEliece].
Goppa コードのシンドローム復号化の硬度に基づく KEM。Goppa コードは、送信メッセージ内の一定数のエラーを訂正できるエラー訂正コードの一種です。デコードの問題には、受信したノイズのあるコードワードから元のメッセージを復元することが含まれます。[クラシックマックエリス]を参照してください。
NTRU:
NTRU:
KEM based on the "N-th degree Truncated polynomial Ring Units" (NTRU) lattices. Variants include Streamlined NTRU Prime (sntrup761), which is leveraged for use in SSH [RFC9941]. See [NTRU].
KEM は、「N 次切頭多項式リング ユニット」(NTRU) 格子に基づいています。バリアントには、SSH [RFC9941] での使用に利用される Streamlined NTRU Prime (sntrup761) が含まれます。[NTRU] を参照してください。
The timeline and driving motivation for transition differ slightly between data confidentiality (e.g., encryption) and data authentication (e.g., signature) use cases.
データ機密性 (暗号化など) とデータ認証 (署名など) のユースケースでは、移行のタイムラインと推進動機が若干異なります。
For data confidentiality, one is concerned with the so-called "harvest now, decrypt later" (HNDL) attack where a malicious actor with adequate resources can launch an attack to store sensitive encrypted data today that they hope to decrypt once a CRQC is available. This implies that, every day, sensitive encrypted data is susceptible to the attack by not implementing quantum-safe strategies, as it corresponds to data possibly being deciphered in the future.
データの機密性に関しては、いわゆる「今すぐ収穫し、後で復号化する」（HNDL）攻撃が懸念されます。HNDL 攻撃では、適切なリソースを持った悪意のある攻撃者が、CRQC が利用可能になったら復号化したいと考えている機密暗号化データを今日保存するために攻撃を開始できます。これは、暗号化された機密データは、将来的に解読される可能性のあるデータに対応するため、量子安全戦略を実装しないことで毎日攻撃を受けやすいことを意味します。
For authentication, it is often the case that signatures have a very short lifetime between signing and verifying (such as during a TLS handshake), but some authentication use cases do require long lifetimes, such as signing firmware or software that will be active for decades, signing legal documents, or signing certificates that will be embedded into hardware devices such as smart cards. Even for short-lived signature use cases, the infrastructure often relies on long-lived root keys, which can be difficult to update or replace on in-field devices.
認証の場合、署名と検証の間 (TLS ハンドシェイク時など) の署名の有効期間が非常に短いことがよくありますが、数十年間アクティブになるファームウェアやソフトウェアへの署名、法的文書への署名、スマート カードなどのハードウェア デバイスに埋め込まれる証明書への署名など、一部の認証ユースケースでは長い有効期間が必要になります。有効期間が短い署名の使用例であっても、インフラストラクチャは有効期間の長いルート キーに依存することが多く、フィールド内のデバイスで更新したり置き換えたりするのは困難な場合があります。
+------------------------+----------------------------+
| | |
| y | x |
+------------------------+----------+-----------------+
| | <--------------->
| z | Security gap
+-----------------------------------+
Figure 1: Mosca Model
図 1: モスカ モデル
These challenges are illustrated nicely by the so-called Mosca model discussed in [Threat-Report]. In Figure 1, "x" denotes the time that systems and data need to remain secure, "y" the number of years to fully migrate to a PQC infrastructure, and "z" the time until a CRQC that can break current cryptography is available. The model assumes either that encrypted data can be intercepted and stored before the migration is completed in "y" years, or that signatures will still be relied upon for "x" years after their creation. This data remains vulnerable for the complete "x" years of their lifetime; thus, the sum "x+y" gives us an estimate of the full timeframe that data remains insecure. The model essentially asks how one is preparing IT systems during those "y" years (in other words, how one can minimize those "y" years) to minimize the transition phase to a PQC infrastructure and hence minimize the risks of data being exposed in the future.
これらの課題は、[Threat-Report] で説明されているいわゆる Mosca モデルによってうまく説明されています。図 1 では、「x」はシステムとデータの安全性を維持する必要がある時間を示し、「y」は PQC インフラストラクチャに完全に移行するまでの年数を、「z」は現在の暗号化を破ることができる CRQC が利用可能になるまでの時間を示しています。このモデルでは、移行が "y" 年以内に完了する前に暗号化されたデータが傍受され保存される可能性がある、または署名が作成されてから "x" 年間信頼され続けることを前提としています。このデータは、その生涯のうち「x」年間ずっと脆弱なままです。したがって、合計「x+y」により、データが安全でない状態が続く全期間の推定値が得られます。このモデルは基本的に、PQC インフラストラクチャへの移行段階を最小限に抑え、将来のデータ漏洩のリスクを最小限に抑えるために、その「y」年間に IT システムをどのように準備するか (つまり、その「y」年間をどのように最小限に抑えることができるか) を問うものです。
Finally, other factors that could accelerate the introduction of a CRQC should not be underestimated, for example, faster-than-expected advances in quantum computing and more efficient versions of Shor's algorithm requiring fewer qubits. Innovation often comes in waves, so it is to the industry's benefit to remain vigilant and prepare as early as possible. Also, bear in mind that while the industry tracks advances from public research institutions such as universities and companies that publish their results, there is also a great deal of large-budget quantum research being conducted privately by various national interests. Therefore, the true state of quantum computer advancement is likely several years ahead of the publicly available research at the date this document is published.
最後に、CRQC の導入を加速する可能性のある他の要因、たとえば、量子コンピューティングの予想よりも速い進歩や、より少ない量子ビットを必要とするショールのアルゴリズムのより効率的なバージョンなどを過小評価すべきではありません。イノベーションには波があることが多いため、常に警戒を怠らず、できるだけ早く準備を整えることが業界の利益になります。また、業界は結果を発表する大学や企業などの公的研究機関の進歩を追跡している一方で、さまざまな国益によって非公開で多額の予算を投じて量子研究が実施されているものも多いことにも留意してください。したがって、量子コンピューターの進歩の真の状況は、この文書が発行された時点で一般に入手可能な研究よりも数年先である可能性があります。
Organizations should also carefully and honestly consider what their migration timeline "y" actually is. If you only think of the time between receiving a patch from your technology vendor and rolling that patch out, then "y" might seem as short as a few weeks. However, this represents the minority of migration cases; more often, a PQC migration will involve at least some amount of hardware replacement. For example, performance-sensitive applications will need CPUs with PQC hardware acceleration. Security-sensitive applications will need PQC TPMs, Trusted Execution Environments (TEEs), secure enclaves, and other cryptographic co-processors. Smart card applications will require replacement of the cards and readers. The readers can come in many form factors: tap-for-entry door and turnstile readers, PIN pad machines, laptops with built-in smart card readers, and many others.
また、組織は、移行スケジュール「y」が実際にどのようなものであるかを慎重かつ正直に検討する必要があります。テクノロジー ベンダーからパッチを受け取ってからそのパッチを展開するまでの時間だけを考えると、「y」は数週間ほど短く見えるかもしれません。ただし、これは少数の移行ケースに相当します。多くの場合、PQC の移行には少なくともある程度のハードウェアの交換が必要になります。たとえば、パフォーマンス重視のアプリケーションには、PQC ハードウェア アクセラレーションを備えた CPU が必要です。セキュリティに敏感なアプリケーションには、PQC TPM、信頼された実行環境 (TEE)、セキュア エンクレーブ、およびその他の暗号化コプロセッサが必要です。スマート カード アプリケーションでは、カードとリーダーの交換が必要になります。リーダーには、タップ式ドアおよび改札口リーダー、PIN パッド マシン、スマート カード リーダーを内蔵したラップトップなど、さまざまなフォーム ファクターがあります。
Included in "y" is not only the deployment time but also the preparation time: integration, testing, auditing, and recertification of cryptographic environments. Also consider upstream effects that contribute to "y", including lead times for vendors to produce PQC-ready products, which may itself include auditing and certification delays, time for regulating bodies to adopt PQC policies, time for auditors to become familiar with the new requirements, etc. If you measure the full migration time "y" from when your vendors begin implementing PQC functionality to when you switch off your last non-PQC-capable device, then "y" can be quite long, likely measured in years for even most moderately sized organizations. This long tail should not discourage early action.
「y」には、展開時間だけでなく、暗号環境の統合、テスト、監査、再認証などの準備時間も含まれます。また、ベンダーが PQC 対応製品を製造するまでのリード タイム (監査や認証の遅延、規制機関が PQC ポリシーを採用するまでの時間、監査人が新しい要件に慣れるまでの時間など) を含む、上流の影響も考慮してください。ベンダーが PQC 機能の実装を開始してから、最後の PQC 非対応デバイスの電源を切るまでの完全な移行時間 "y" を測定すると、"y" は非常に長くなり、おそらく数年に及ぶ可能性があります。ほとんどの中規模の組織。このロングテールによって早期の行動が妨げられるべきではありません。
Organizations responsible for protecting long-lived sensitive data or operating critical infrastructure will need to begin transitioning immediately, particularly in scenarios where data is vulnerable to HNDL attacks. Post-quantum and traditional (PQ/T) Section 13 or PQ key exchange is relatively self-contained, typically requiring changes only to the cryptographic library (e.g., OpenSSL). In contrast, migrating to post-quantum or PQ/T digital signatures involves broader ecosystem changes, including updates to certificates, certification authorities (CAs), Certificate Management Protocols, HSMs, and trust anchors. Starting early with hybrid key exchange deployments allows organizations to gain operational experience, while prototyping and planning for PQ/T or PQ digital signature integration helps identify ecosystem-wide impacts early. This phased approach reduces long-term migration risks and ensures readiness for more complex updates.
長期にわたる機密データの保護や重要なインフラストラクチャの運用を担当する組織は、特にデータが HNDL 攻撃に対して脆弱であるシナリオでは、直ちに移行を開始する必要があります。ポスト量子および従来型 (PQ/T) セクション 13 または PQ 鍵交換は比較的自己完結型であり、通常は暗号ライブラリ (OpenSSL など) への変更のみが必要です。対照的に、ポスト量子または PQ/T デジタル署名への移行には、証明書、認証局 (CA)、証明書管理プロトコル、HSM、トラスト アンカーの更新など、より広範なエコシステムの変更が伴います。ハイブリッド鍵交換の導入を早期に開始することで、組織は運用経験を積むことができると同時に、PQ/T または PQ デジタル署名統合のプロトタイピングと計画を立てて、エコシステム全体への影響を早期に特定するのに役立ちます。この段階的なアプローチにより、長期的な移行リスクが軽減され、より複雑な更新への準備が確実に整います。
The post-quantum cryptographic schemes standardized by NIST can be categorized into three main groups: lattice-based, hash-based, and code-based. Other approaches, such as isogeny-based, multivariate-based, and MPC-in-the-Head-based cryptography, are also being explored in research and standardization efforts. In addition, NIST issued a call for additional digital signature proposals to expand the set of post-quantum signatures under evaluation [AddSig].
NIST によって標準化されたポスト量子暗号方式は、ラティスベース、ハッシュベース、コードベースの 3 つの主要なグループに分類できます。同種生成ベース、多変量ベース、MPC-in-the-Head ベースの暗号化などの他のアプローチも、研究と標準化の取り組みで検討されています。さらに、NIST は、評価中のポスト量子署名のセットを拡張するための追加のデジタル署名提案の募集を発行しました [AddSig]。
Lattice-based public key cryptography leverages the simple construction of lattices (i.e., a regular collection of points in a Euclidean space that are evenly spaced) to create "trapdoor" problems. These problems are efficient to compute if you possess the secret information but challenging to compute otherwise. Examples of such problems include the shortest vector, closest vector, short integer solution, learning with errors, module learning with errors, and learning with rounding problems. All of these problems feature strong proofs for worst-to-average case reduction, effectively relating the hardness of the average case to the worst case.
格子ベースの公開キー暗号化では、単純な格子構造 (つまり、ユークリッド空間内の等間隔の点の規則的な集合) を利用して、「落とし戸」問題を作成します。これらの問題は、秘密情報を持っている場合は効率的に計算できますが、そうでない場合は計算が困難です。このような問題の例としては、最短ベクトル、最近接ベクトル、短整数解、エラーを伴う学習、エラーを伴うモジュール学習、丸め問題を伴う学習などがあります。これらの問題はすべて、最悪のケースを平均的なケースに減らすための強力な証明を特徴としており、平均的なケースの困難さを最悪のケースに効果的に関連付けます。
Lattice-based public keys and signatures are larger than those of classical schemes such as RSA or ECC, but typically by less than an order of magnitude for public keys (about 6-10x) and by roughly one to two orders of magnitude for signatures (about 10-100x) rather than by several orders of magnitude, making them the best available candidates for general-purpose use, such as replacing the use of RSA in PKIX certificates.
格子ベースの公開鍵と署名は、RSA や ECC などの古典的なスキームよりも大きくなりますが、通常、公開鍵の場合は 1 桁未満 (約 6 ～ 10 倍)、署名の場合は数桁ではなく約 1 ～ 2 桁 (約 10 ～ 100 倍) であり、PKIX 証明書での RSA の使用の置き換えなど、汎用用途に使用できる最良の候補となります。
Examples of this class of algorithms include ML-KEM, FN-DSA, ML-DSA, and FrodoKEM.
このクラスのアルゴリズムの例には、ML-KEM、FN-DSA、ML-DSA、FrodoKEM などがあります。
It is noteworthy that lattice-based encryption schemes require a rounding step during decryption, which has a non-zero probability of "rounding the wrong way" and leading to a decryption failure, meaning that valid encryptions are decrypted incorrectly. However, the parameters of NIST PQC candidates are carefully chosen so that the probability of such a failure is cryptographically negligible, far lower than the probability of random transmission errors and implementation bugs. In practical terms, these rare decryption failures can be treated the same way as any fatal transport error: Both sides simply perform a fresh KEM operation, generating a new ciphertext and shared secret.
注目すべき点は、格子ベースの暗号化スキームでは復号化中に丸めステップが必要であり、これにより「間違った方法で丸められ」、復号化の失敗につながる可能性がゼロではなく、有効な暗号化が正しく復号化されないことになります。ただし、NIST PQC 候補のパラメータは、そのような失敗の確率が暗号的に無視できる程度になるように慎重に選択されており、ランダムな送信エラーや実装バグの確率よりもはるかに低くなります。実際には、これらのまれな復号エラーは、致命的なトランスポート エラーと同じように扱うことができます。つまり、双方が新しい KEM 操作を実行して、新しい暗号文と共有秘密を生成するだけです。
In cryptanalysis, an oracle refers to a system that an attacker can query to learn whether decryption succeeded or failed. If such an oracle exists, an attacker could significantly reduce the security of lattice-based schemes that have a relatively high failure rate. However, for most of the NIST PQC proposals, the number of required oracle queries to force a decryption failure is above practical limits, as shown in [LattFail1]. More recent works have improved upon the results in [LattFail1], showing that the cost of searching for additional failing ciphertexts after one or more have already been found can be sped up dramatically [LattFail2]. Nevertheless, at the time this document is published, the PQC candidates by NIST are considered secure under these attacks, and constant monitoring as cryptanalysis research is ongoing.
暗号解析において、オラクルとは、攻撃者が復号化が成功したか失敗したかを知るためにクエリできるシステムを指します。このようなオラクルが存在すると、攻撃者は失敗率が比較的高い格子ベースのスキームのセキュリティを大幅に低下させる可能性があります。しかし、NIST PQC 提案のほとんどでは、[LattFail1] に示されているように、強制的に復号化を失敗させるために必要な Oracle クエリの数が実用的な制限を超えています。最近の研究は [LattFail1] の結果を改良しており、1 つ以上の失敗した暗号文がすでに見つかった後に追加で失敗する暗号文を検索するコストが劇的に高速化できることを示しています [LattFail2]。それにもかかわらず、この文書が公開された時点では、NIST による PQC 候補はこれらの攻撃に対して安全であると考えられており、暗号解読研究が進行中であるため、継続的な監視が行われています。
Hash-based Public Key Cryptography (Hash-based PKC) has been around since the 1970s, when it was developed by Lamport and Merkle. It is used to create digital signature algorithms, and its security is based on the security of the underlying cryptographic hash function. Many variants of hash-based signatures (HBSs) have been developed since the 1970s, including the recent XMSS [RFC8391], HSS/LMS [RFC8554], or BPQS [BPQS] schemes. Unlike many other digital signature techniques, most hash-based signature schemes are stateful, which means that signing necessitates the update and careful tracking of the state of the secret key. Producing multiple signatures using the same secret key state results in loss of security and may ultimately enable signature forgery attacks against that key.
ハッシュベースの公開キー暗号化 (ハッシュベース PKC) は、Lamport と Merkle によって開発された 1970 年代から存在しています。これはデジタル署名アルゴリズムの作成に使用され、そのセキュリティは基礎となる暗号ハッシュ関数のセキュリティに基づいています。最近の XMSS [RFC8391]、HSS/LMS [RFC8554]、または BPQS [BPQS] スキームを含め、ハッシュベース署名 (HBS) の多くの変種が 1970 年代以来開発されてきました。他の多くのデジタル署名技術とは異なり、ほとんどのハッシュベースの署名スキームはステートフルです。つまり、署名には秘密キーの状態の更新と注意深い追跡が必要です。同じ秘密鍵の状態を使用して複数の署名を作成すると、セキュリティが失われ、最終的にはその鍵に対する署名偽造攻撃が可能になる可能性があります。
Stateful hash-based signatures with long service lifetimes require additional operational complexity compared to other signature types. For example, consider a 20-year root key; there is an expectation that 20 years is longer than the expected lifetime of the hardware that key is stored on, so the key will need to be migrated to new hardware at some point. Disaster-recovery scenarios where the primary node fails without warning can be similarly tricky. This requires careful operational and compliance consideration to ensure that no private key state can be reused across the migration or disaster recovery event. One approach for avoiding these issues is to only use stateful HBSs for short-term use cases that do not require horizontal scaling, for example, signing a batch of firmware images and then retiring the signing key.
サービス寿命が長いステートフル ハッシュ ベースの署名は、他の署名タイプに比べて運用の複雑さがさらに必要になります。たとえば、20 年間のルート キーを考えてみましょう。キーが保存されているハードウェアの予想寿命よりも 20 年は長いと予想されるため、ある時点でキーを新しいハードウェアに移行する必要があります。警告なしにプライマリ ノードに障害が発生する災害復旧シナリオも同様に困難になる可能性があります。これには、移行または災害復旧イベント全体で秘密キーの状態が再利用できないようにするために、運用とコンプライアンスを慎重に考慮する必要があります。これらの問題を回避する 1 つのアプローチは、水平方向のスケーリングを必要としない短期的なユースケース (ファームウェア イメージのバッチに署名して署名キーを破棄するなど) にのみステートフル HBS を使用することです。
The SLH-DSA algorithm, which was standardized by NIST, leverages the HORST (Hash to Obtain Random Subset with Trees) technique and remains the only standardized hash based signature scheme that is stateless, thus avoiding the complexities associated with state management. SLH-DSA is an advancement on SPHINCS that reduces the signature sizes in SPHINCS and makes it more compact.
NIST によって標準化された SLH-DSA アルゴリズムは、HORST (Hash to Obtain Random Subset with Trees) 技術を利用しており、ステートレスで標準化された唯一のハッシュ ベースの署名スキームであり、そのため状態管理に関連する複雑さを回避します。SLH-DSA は、SPHINCS の署名サイズを削減し、よりコンパクトにする SPHINCS の進歩です。
This area of cryptography started in the 1970s and 1980s and was based on the seminal work of McEliece and Niederreiter, which focuses on the study of cryptosystems based on error-correcting codes. Some popular error-correcting codes include Goppa codes (used in McEliece cryptosystems), encoding and decoding syndrome codes used in HQC, or quasi-cyclic moderate density parity check (QC-MDPC) codes.
この分野の暗号化は 1970 年代と 1980 年代に始まり、誤り訂正符号に基づく暗号システムの研究に焦点を当てた McEliece と Niederreiter の独創的な研究に基づいていました。一般的な誤り訂正符号には、Goppa コード (McEliece 暗号システムで使用)、HQC で使用されるエンコードおよびデコードのシンドローム コード、準巡回中密度パリティ チェック (QC-MDPC) コードなどがあります。
Examples include all the unbroken NIST Round 4 finalists: Classic McEliece, HQC (selected by NIST for standardization), and Bit Flipping Key Encapsulation (BIKE) [BIKE].
例としては、現在まで続く NIST ラウンド 4 のファイナリストすべて、Classic McEliece、HQC (標準化のために NIST によって選択)、および Bit Flipping Key Encapsulation (BIKE) [BIKE] が含まれます。
A Key Encapsulation Mechanism (KEM) is a cryptographic technique used for securely exchanging symmetric key material between two parties over an insecure channel. It is commonly used in hybrid encryption schemes where a combination of asymmetric (public key) and symmetric encryption is employed. The encapsulation operation of a KEM results in a fixed-length symmetric key that can be used with a symmetric algorithm, typically a block cipher, in one of two different ways:
キー カプセル化メカニズム (KEM) は、安全でないチャネルを介して 2 者間で対称キー マテリアルを安全に交換するために使用される暗号化技術です。これは、非対称 (公開キー) 暗号化と対称暗号化の組み合わせが使用されるハイブリッド暗号化スキームで一般的に使用されます。KEM のカプセル化操作により、次の 2 つの異なる方法のいずれかで、対称アルゴリズム (通常はブロック暗号) で使用できる固定長の対称キーが生成されます。
* To derive a data encryption key (DEK) to encrypt the data
* データを暗号化するためのデータ暗号化キー (DEK) を導出するには
* To derive a key encryption key (KEK) used to wrap a DEK
* DEK のラップに使用されるキー暗号化キー (KEK) を取得するには
These techniques are often referred to as the Hybrid Public Key Encryption (HPKE) [RFC9180] mechanism.
これらの技術は、ハイブリッド公開キー暗号化 (HPKE) [RFC9180] メカニズムと呼ばれることがよくあります。
The term "encapsulation" is chosen intentionally to indicate that KEM algorithms behave differently at the API level from the key agreement or key encipherment and key transport mechanisms that are in use today. Key agreement schemes imply that both parties contribute a public-private key pair to the exchange, while key encipherment and key transport schemes imply that the symmetric key material is chosen by one party and "encrypted" or "wrapped" for the other party. KEMs, on the other hand, behave according to the following API primitives [PQCAPI]:
「カプセル化」という用語は、KEM アルゴリズムが API レベルで現在使用されているキー合意、キー暗号化、およびキー転送メカニズムとは異なる動作をすることを示すために意図的に選択されています。鍵合意スキームは、両当事者が公開鍵と秘密鍵のペアを交換に提供することを意味しますが、鍵暗号化および鍵転送スキームは、対称鍵マテリアルが一方の当事者によって選択され、もう一方の当事者のために「暗号化」または「ラップ」されることを意味します。一方、KEM は次の API プリミティブ [PQCAPI] に従って動作します。
* def kemKeyGen() -> (pk, sk)
* def kemKeyGen() -> (pk, sk)
* def kemEncaps(pk) -> (ss, ct)
* def kemEncaps(pk) -> (ss, ct)
* def kemDecaps(ct, sk) -> ss
* def kemDecaps(ct, sk) -> ss
where pk is the public key, sk is the secret key, ct is the ciphertext representing an encapsulated key, and ss is the shared secret. The following figure illustrates a sample flow of a KEM-based key exchange:
ここで、pk は公開キー、sk は秘密キー、ct はカプセル化されたキーを表す暗号文、ss は共有秘密です。次の図は、KEM ベースのキー交換のサンプル フローを示しています。
+---------+ +---------+
| Client | | Server |
+---------+ +---------+
+----------------------+ | |
| pk, sk = kemKeyGen() |-| |
+----------------------+ | |
| |
| pk |
|---------->|
| | +-----------------------+
| |-| ss, ct = kemEncaps(pk)|
| | +-----------------------+
| |
| ct |
|<----------|
+------------------------+ | |
| ss = kemDecaps(ct, sk) |-| |
+------------------------+ | |
| |
Figure 2: KEM-Based Key Exchange
図 2: KEM ベースの鍵交換
Authenticated Key Exchange (AKE) with KEMs where both parties contribute a KEM public key to the overall session key is interactive as described in Section 9.4 of [RFC9528]. However, a single-sided KEM, such as when one peer has a KEM key in a certificate and the other peer wants to encrypt for it (as in S/MIME or OpenPGP email), can be achieved using non-interactive HPKE [RFC9180]. The following figure illustrates the DH Key exchange:
[RFC9528] のセクション 9.4 で説明されているように、双方がセッション鍵全体に KEM 公開鍵を提供する KEM との認証鍵交換 (AKE) は対話型です。ただし、一方のピアが証明書に KEM キーを持っていて、もう一方のピアがそれを暗号化したい場合 (S/MIME や OpenPGP 電子メールなど) の片面 KEM は、非対話型 HPKE [RFC9180] を使用して実現できます。次の図は、DH キーの交換を示しています。
+---------+ +---------+
| Client | | Server |
+---------+ +---------+
+-----------------------+ | |
| Long-term client key: | | |
| sk1, pk1 |-| |
+-----------------------+ | |
| |
| pk1 |
|---------->|
| | +------------------------+
| |-| Long-term server key: |
| | | sk2, pk2 |
| | | ss = KeyEx(pk1, sk2) |
| | +------------------------+
| |
| pk2|
|<----------|
+-------------------------+ | |
| ss = KeyEx(pk2, sk1) | | |
| encryptContent(ss) |-| |
+-------------------------+ | |
| encrypted |
| content |
|---------->|
| | +------------------------+
| | | decryptContent(ss) |
| | +------------------------+
Figure 3: DH-Based AKE
図 3: DH ベースの AKE
In the sample flow above, it is important to note that the shared secret ss is derived using key material from both the client and the server, which classifies it as an AKE. There is another property of a key exchange, called Non-Interactive Key Exchange (NIKE), that refers to whether the sender can compute the shared secret ss and encrypt content without requiring active interaction (an exchange of network messages) with the recipient. Figure 3 shows a DH key exchange, which is an AKE since both parties are using long-term keys that can have established trust (for example, via certificates), but it is not a NIKE since the client needs to wait for the network interaction to receive the receiver's public key pk2 before it can compute the shared secret ss and begin content encryption. However, a DH key exchange can be an AKE and a NIKE at the same time if the receiver's public key is known to the sender in advance (see Figure 4), and many Internet protocols rely on this property of DH-based key exchanges.
上記のサンプル フローでは、共有秘密 ss がクライアントとサーバーの両方からのキー マテリアルを使用して導出され、それが AKE として分類されることに注意することが重要です。キー交換には、非対話型キー交換 (NIKE) と呼ばれる別のプロパティがあります。これは、送信者が受信者とのアクティブな対話 (ネットワーク メッセージの交換) を必要とせずに共有秘密 ss を計算し、コンテンツを暗号化できるかどうかを指します。図 3 は、DH 鍵交換を示しています。これは、双方が信頼を確立できる長期鍵 (証明書などを介して) を使用しているため、AKE ですが、クライアントは、共有秘密 ss を計算してコンテンツの暗号化を開始する前に、ネットワーク対話が受信者の公開鍵 pk2 を受信するのを待つ必要があるため、NIKE ではありません。ただし、受信者の公開鍵が送信者に事前に知られている場合、DH 鍵交換は同時に AKE と NIKE になることができ (図 4 を参照)、多くのインターネット プロトコルは DH ベースの鍵交換のこの特性に依存しています。
+---------+ +---------+
| Client | | Server |
+---------+ +---------+
+-----------------------+ | |
| Long-term client key: | | |
| sk1, pk1 |-| |
| Long-term server key: | | |
| pk2 | | |
| ss = KeyEx(pk2, sk1) | | |
| encryptContent(ss) |-| |
+-----------------------+ | |
| |
| pk1, |
| encrypted |
| content |
|---------->|
| | +------------------------+
| |-| Long-term server key: |
| | | sk2, pk2 |
| | | ss = KeyEx(pk1, sk2) |
| | | decryptContent(ss) |
| | +------------------------+
Figure 4: Simultaneous DH-Based AKE and NIKE
図 4: DH ベースの AKE と NIKE の同時実行
The complication with KEMs is that a KEM Encaps() is non-deterministic; it involves randomness chosen by the sender of that message. Therefore, in order to perform an AKE, the client must wait for the server to generate the needed randomness and perform Encaps() against the client key, which necessarily requires a network round-trip. Therefore, a KEM-based protocol can either be an AKE or a NIKE, but it cannot be both at the same time. Consequently, certain Internet protocols will necessitate a redesign to accommodate this distinction, either by introducing extra network round trips or by making trade-offs in security properties.
KEM の複雑な点は、KEM Encaps() が非決定的であることです。これには、メッセージの送信者によって選択されたランダム性が含まれます。したがって、AKE を実行するには、クライアントはサーバーが必要なランダム性を生成し、クライアント キーに対して Encaps() を実行するのを待つ必要があり、これには必然的にネットワーク ラウンドトリップが必要になります。したがって、KEM ベースのプロトコルは AKE または NIKE のいずれかになりますが、同時に両方になることはできません。したがって、特定のインターネット プロトコルでは、追加のネットワーク ラウンド トリップを導入するか、セキュリティ特性をトレードオフすることによって、この区別に対応するための再設計が必要になります。
+---------+ +---------+
| Client | | Server |
+---------+ +---------+
+------------------------+ | |
| pk1, sk1 = kemKeyGen() |-| |
+------------------------+ | |
| |
|pk1 |
|---------->|
| | +--------------------------+
| |-| ss1, ct1 = kemEncaps(pk1)|
| | | pk2, sk2 = kemKeyGen() |
| | +--------------------------+
| |
| ct1,pk2|
|<----------|
+--------------------------+ | |
| ss1 = kemDecaps(ct1, sk1)| | |
| ss2, ct2 = kemEncaps(pk2)|-| |
| ss = Combiner(ss1, ss2) | | |
+--------------------------+ | |
| |
|ct2 |
|---------->|
| | +--------------------------+
| |-| ss2 = kemDecaps(ct2, sk2)|
| | | ss = Combiner(ss1, ss2) |
| | +--------------------------+
Figure 5: KEM-Based AKE
図 5: KEM ベースの AKE
In the figure above, Combiner(ss1, ss2), often referred to as a KEM combiner, is a cryptographic construction that takes in two shared secrets and returns a single combined shared secret. The simplest combiner is concatenation ss1 || ss2, but combiners can vary in complexity depending on the cryptographic properties required. For example, if the combination should preserve IND-CCA2 (see Section 9.2.1) of either input, even if the other is chosen maliciously, then a more complex construct is required. Another consideration for combiner design is the so-called "binding properties" introduced in [KEEPINGUP], which may require the ciphertexts and recipient public keys to be included in the combiner. KEM combiner security analysis becomes more complicated in hybrid settings where the two KEMs represent different algorithms, for example, where one is ML-KEM and the other is ECDH. For a more thorough discussion of KEM combiners, see [KEEPINGUP], [KEM-COMBINER], and [PQ-KEM].
上の図の Combiner(ss1, ss2) は、KEM コンバイナーと呼ばれることが多く、2 つの共有シークレットを受け取り、結合された 1 つの共有シークレットを返す暗号構造です。最も単純な結合器は連結 ss1 || です。ss2 と同様ですが、コンバイナの複雑さは、必要な暗号化プロパティに応じて異なります。たとえば、組み合わせがどちらかの入力の IND-CCA2 (セクション 9.2.1 を参照) を保持する必要がある場合、たとえもう一方が悪意を持って選択されたとしても、より複雑な構成が必要です。コンバイナーの設計に関するもう 1 つの考慮事項は、[KEEPINGUP] で導入されたいわゆる「バインディング プロパティ」です。これは、暗号文と受信者の公開鍵をコンバイナーに含めることを必要とする場合があります。KEM コンバイナーのセキュリティ分析は、2 つの KEM が異なるアルゴリズムを表すハイブリッド設定 (たとえば、一方が ML-KEM、もう一方が ECDH である場合) ではさらに複雑になります。KEM コンバイナーの詳細については、[KEEPINGUP]、[KEM-COMBINER]、および [PQ-KEM] を参照してください。
The security properties described in this section (IND-CCA2 and binding) are not an exhaustive list of all possible KEM security considerations. They were selected because they are fundamental to evaluating KEM suitability in protocol design and are commonly discussed in current PQC work.
このセクションで説明するセキュリティ プロパティ (IND-CCA2 およびバインディング) は、考えられるすべての KEM セキュリティ考慮事項の完全なリストではありません。これらが選択されたのは、プロトコル設計における KEM 適合性を評価するための基礎であり、現在の PQC 作業で一般的に議論されているためです。
IND-CCA2 (INDistinguishability under adaptive Chosen-Ciphertext Attack) is an advanced security notion for encryption schemes. It ensures the confidentiality of the plaintext and resistance against chosen-ciphertext attacks. An appropriate definition of IND-CCA2 security for KEMs can be found in [CS01] and [BHK09]. ML-KEM [ML-KEM] and Classic McEliece provide IND-CCA2 security.
IND-CCA2 (適応型選択暗号文攻撃における INDistinguishability) は、暗号化方式の高度なセキュリティ概念です。これにより、平文の機密性と選択暗号文攻撃に対する耐性が保証されます。KEM の IND-CCA2 セキュリティの適切な定義は、[CS01] および [BHK09] にあります。ML-KEM [ML-KEM] および Classic McEliece は、IND-CCA2 セキュリティを提供します。
Understanding IND-CCA2 security is essential for individuals involved in designing or implementing cryptographic systems and protocols in order to evaluate the strength of the algorithm, assess its suitability for specific use cases, and ensure that data confidentiality and security requirements are met. Understanding IND-CCA2 security is generally not necessary for developers migrating to using an IETF-vetted KEM within a given protocol or flow. IND-CCA2 is a widely accepted security notion for public key encryption mechanisms, making it suitable for a broad range of applications. When an IETF specification defines a new KEM, its security considerations should fully describe the relevant cryptographic properties, including IND-CCA2.
IND-CCA2 セキュリティを理解することは、アルゴリズムの強度を評価し、特定のユースケースへの適合性を評価し、データの機密性とセキュリティ要件が確実に満たされていることを確認するために、暗号化システムおよびプロトコルの設計または実装に携わる個人にとって不可欠です。通常、特定のプロトコルまたはフロー内で IETF 審査済みの KEM の使用に移行する開発者にとって、IND-CCA2 セキュリティを理解する必要はありません。IND-CCA2 は公開キー暗号化メカニズムとして広く受け入れられているセキュリティ概念であり、幅広いアプリケーションに適しています。IETF 仕様で新しい KEM を定義する場合、そのセキュリティに関する考慮事項で、IND-CCA2 を含む関連する暗号化プロパティを完全に説明する必要があります。
KEMs also have an orthogonal set of properties to consider when designing protocols around them: binding [KEEPINGUP]. This can be "ciphertext binding", "public key binding", "context binding", or any other property that is important to not be substituted between KEM invocations. In general, a KEM is considered to bind a certain value if substitution of that value by an attacker will necessarily result in a different shared secret being derived. As an example, if an attacker can construct two different ciphertexts that will decapsulate to the same shared secret, can construct a ciphertext that will decapsulate to the same shared secret under two different public keys, or can substitute whole KEM exchanges from one session into another, then the construction is not ciphertext binding, public key binding, or context binding, respectively. Similarly, protocol designers may wish to bind protocol state information such as a transaction ID or nonce so that attempts to replay ciphertexts from one session inside a different session will be blocked at the cryptographic level because the server derives a different shared secret and is thus is unable to decrypt the content.
KEM には、その周囲のプロトコルを設計する際に考慮すべき直交する一連のプロパティ、つまりバインディング [KEEPINGUP] もあります。これには、「暗号文バインディング」、「公開キー バインディング」、「コンテキスト バインディング」、または KEM 呼び出し間で置き換えられないことが重要なその他のプロパティを指定できます。一般に、攻撃者による特定の値の置換によって必然的に別の共有秘密が導出される場合、KEM は特定の値をバインドするとみなされます。たとえば、攻撃者が同じ共有秘密にカプセル化を解除する 2 つの異なる暗号文を構築できる場合、2 つの異なる公開鍵に基づいて同じ共有秘密にカプセル化を解除する暗号文を構築できる場合、または KEM 交換全体を 1 つのセッションから別のセッションに置き換えることができる場合、その構築はそれぞれ暗号文バインディング、公開キー バインディング、またはコンテキスト バインディングではありません。同様に、プロトコル設計者は、トランザクション ID や nonce などのプロトコル状態情報をバインドし、サーバーが別の共有秘密を導出し、コンテンツを復号化できないため、あるセッションから別のセッション内で暗号文を再生しようとする試みが暗号レベルでブロックされるようにしたい場合があります。
The solution to binding is generally achieved at the protocol design level: It is recommended to avoid using the KEM output shared secret directly without integrating it into an appropriate protocol. While KEM algorithms provide key secrecy, they do not inherently ensure source authenticity, protect against replay attacks, or guarantee freshness. These security properties should be addressed by incorporating the KEM into a protocol that has been analyzed for such protections. Even though modern KEMs such as ML-KEM produce full-entropy shared secrets, it is still advisable for binding reasons to pass the shared secret through a key derivation function (KDF) and also include all values that you wish to bind; finally, you will have a shared secret that is safe to use at the protocol level.
バインディングの解決策は通常、プロトコル設計レベルで実現されます。KEM 出力共有秘密を適切なプロトコルに統合せずに直接使用することは避けることをお勧めします。KEM アルゴリズムはキーの機密性を提供しますが、本質的にソースの信頼性を保証したり、リプレイ攻撃から保護したり、鮮度を保証したりするものではありません。これらのセキュリティ特性は、そのような保護のために分析されたプロトコルに KEM を組み込むことによって対処する必要があります。ML-KEM などの最新の KEM はフルエントロピーの共有シークレットを生成しますが、バインディングの理由から、キー導出関数 (KDF) を介して共有シークレットを渡し、バインドするすべての値も含めることをお勧めします。最終的に、プロトコル レベルで安全に使用できる共有秘密が得られます。
Modern cryptography has long used the notion of "hybrid encryption" where an asymmetric algorithm is used to establish a key and then a symmetric algorithm is used for bulk content encryption. The previous sections explained important security properties of KEMs, such as IND-CCA2 security and binding, and emphasized that these properties must be supported by proper protocol design. One widely deployed scheme that achieves this is Hybrid Public Key Encryption (HPKE) [RFC9180].
最新の暗号化では、非対称アルゴリズムを使用してキーを確立し、対称アルゴリズムをバルク コンテンツの暗号化に使用する「ハイブリッド暗号化」の概念が長い間使用されてきました。前のセクションでは、IND-CCA2 セキュリティやバインディングなど、KEM の重要なセキュリティ プロパティについて説明し、これらのプロパティが適切なプロトコル設計でサポートされている必要があることを強調しました。これを実現する広く導入されているスキームの 1 つは、ハイブリッド公開キー暗号化 (HPKE) [RFC9180] です。
HPKE [RFC9180] works with a combination of KEMs, KDFs, and Authenticated Encryption with Associated Data (AEAD) schemes. HPKE includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a KEM private key. HPKE can be extended to support hybrid post-quantum KEM [PQ-HPKE]. ML-KEM does not support the static-ephemeral key exchange that allows HPKE that is based on DH-based KEMs and its optional authenticated modes as discussed in Section 1.5 of [X-WING].
HPKE [RFC9180] は、KEM、KDF、および関連データによる認証暗号化 (AEAD) スキームの組み合わせで動作します。HPKE には、事前共有キーの所有を認証する 1 つと、KEM 秘密キーの所有を認証する 2 つのオプションを含む 3 つの認証済みバリアントが含まれています。HPKE は、ハイブリッドポスト量子 KEM [PQ-HPKE] をサポートするように拡張できます。ML-KEM は、[X-WING] のセクション 1.5 で説明されているように、DH ベースの KEM とそのオプションの認証モードに基づく HPKE を可能にする静的一時キー交換をサポートしていません。
Any digital signature scheme that provides a construction defining security under a post-quantum setting falls under this category of PQC signatures.
ポスト量子設定下でセキュリティを定義する構造を提供するデジタル署名スキームは、この PQC 署名のカテゴリに分類されます。
EUF-CMA (existential unforgeability under chosen message attack) [GMR88] is a security notion for digital signature schemes. It guarantees that an adversary, even with access to a signing oracle, cannot forge a valid signature for an arbitrary message. EUF-CMA provides strong protection against forgery attacks, ensuring the integrity and authenticity of digital signatures by preventing unauthorized modifications or fraudulent signatures. ML-DSA, FN-DSA, and SLH-DSA provide EUF-CMA security.
EUF-CMA (選択メッセージ攻撃下における実存的偽造不可能性) [GMR88] は、デジタル署名方式のセキュリティ概念です。これにより、攻撃者が署名オラクルにアクセスしたとしても、任意のメッセージの有効な署名を偽造できないことが保証されます。EUF-CMA は、偽造攻撃に対する強力な保護を提供し、不正な変更や不正な署名を防止することでデジタル署名の完全性と信頼性を保証します。ML-DSA、FN-DSA、および SLH-DSA は EUF-CMA セキュリティを提供します。
SUF-CMA (strong unforgeability under chosen message attack) builds upon EUF-CMA by requiring that an adversary cannot produce a different valid signature for a message that has already been signed by the signing oracle. Like EUF-CMA, SUF-CMA provides robust assurances for digital signature schemes, further enhancing their security posture. ML-DSA, FN-DSA, and SLH-DSA also achieve SUF-CMA security.
SUF-CMA (選択メッセージ攻撃下での強力な偽造可能性) は、署名オラクルによって既に署名されているメッセージに対して敵対者が別の有効な署名を生成できないことを要求することで、EUF-CMA に基づいて構築されています。EUF-CMA と同様に、SUF-CMA はデジタル署名スキームに堅牢な保証を提供し、セキュリティ体制をさらに強化します。ML-DSA、FN-DSA、および SLH-DSA も SUF-CMA セキュリティを実現します。
Understanding EUF-CMA and SUF-CMA security is essential for designing or implementing cryptographic systems in order to ensure the security, reliability, and robustness of digital signature schemes. These notions allow for informed decision making, vulnerability analysis, compliance with standards, and designing systems that provide strong protection against forgery attacks. For developers migrating to an IETF-vetted PQC signature scheme within a given protocol or flow, a deep understanding of EUF-CMA and SUF-CMA security may not be necessary, as the schemes vetted by IETF adhere to these stringent security standards.
EUF-CMA および SUF-CMA のセキュリティを理解することは、デジタル署名方式のセキュリティ、信頼性、堅牢性を確保するために、暗号化システムの設計または実装に不可欠です。これらの概念により、情報に基づいた意思決定、脆弱性分析、標準への準拠、および偽造攻撃に対する強力な保護を提供するシステムの設計が可能になります。特定のプロトコルまたはフロー内で IETF が精査した PQC 署名スキームに移行する開発者にとって、IETF が精査したスキームはこれらの厳格なセキュリティ標準に準拠しているため、EUF-CMA および SUF-CMA のセキュリティを深く理解する必要はない場合があります。
EUF-CMA and SUF-CMA are considered strong security benchmarks for public key signature algorithms, making them suitable for most applications. Authors of IETF specifications should include all security concerns in the "Security Considerations" section of the relevant RFC and should not assume that implementers are experts in cryptographic theory.
EUF-CMA および SUF-CMA は、公開鍵署名アルゴリズムの強力なセキュリティ ベンチマークとみなされ、ほとんどのアプリケーションに適しています。IETF 仕様の作成者は、関連する RFC の「セキュリティに関する考慮事項」セクションにすべてのセキュリティ上の懸念事項を含める必要があり、実装者が暗号理論の専門家であると想定すべきではありません。
ML-DSA [ML-DSA] is a digital signature algorithm based on the hardness of lattice problems over module lattices (i.e., the Module Learning with Errors (MLWE) problem). The design of the algorithm is based on the "Fiat-Shamir with Aborts" [Lyu09] framework introduced by Lyubashevsky that leverages rejection sampling to render lattice-based Fiat-Shamir (FS) schemes compact and secure. ML-DSA uses uniformly distributed random number sampling over small integers to compute coefficients in error vectors, which makes the scheme easier to implement compared to FN-DSA [FN-DSA], which uses Gaussian-distributed numbers, necessitating the need to use floating-point arithmetic during signature generation.
ML-DSA [ML-DSA] は、モジュール格子上の格子問題 (つまり、エラーを伴うモジュール学習 (MLWE) 問題) の難易度に基づいたデジタル署名アルゴリズムです。アルゴリズムの設計は、Lyubashevsky によって導入された「Fiat-Shamir with Aborts」[Lyu09] フレームワークに基づいており、拒否サンプリングを活用して格子ベースの Fiat-Shamir (FS) スキームをコンパクトかつ安全にレンダリングします。ML-DSA は、小さな整数に対して均一に分散された乱数サンプリングを使用して誤差ベクトルの係数を計算します。これにより、ガウス分布数を使用する FN-DSA [FN-DSA] に比べてスキームの実装が容易になり、署名生成中に浮動小数点演算を使用する必要がなくなります。
ML-DSA offers both deterministic and randomized signing and is instantiated with three parameter sets providing different security levels. Security properties of ML-DSA are discussed in Section 9 of [RFC9881].
ML-DSA は決定的署名とランダム化署名の両方を提供し、さまざまなセキュリティ レベルを提供する 3 つのパラメータ セットでインスタンス化されます。ML-DSA のセキュリティ特性は、[RFC9881] のセクション 9 で説明されています。
FN-DSA [FN-DSA] is based on the GPV hash-and-sign lattice-based signature framework introduced by Gentry, Peikert, and Vaikuntanathan, which is a framework that requires a certain class of lattices and a trapdoor sampler technique.
FN-DSA [FN-DSA] は、Gentry、Peikert、および Vaikuntanathan によって導入された GPV ハッシュおよび署名ラティスベースの署名フレームワークに基づいています。これは、特定のクラスのラティスとトラップドア サンプラー技術を必要とするフレームワークです。
The main design principle of FN-DSA is compactness, i.e., it was designed in a way that achieves minimal total memory bandwidth requirement (the sum of the signature size plus the public key size). This is possible due to the compactness of NTRU lattices. FN-DSA also offers very efficient signing and verification procedures. The main potential downsides of FN-DSA refer to the non-triviality of its algorithms and the need for floating-point arithmetic support in order to support Gaussian-distributed random number sampling where the other lattice schemes use the less efficient but easier to support uniformly distributed random number sampling.
FN-DSA の主な設計原則はコンパクトです。つまり、最小の総メモリ帯域幅要件 (署名サイズと公開鍵サイズの合計) を達成する方法で設計されています。これは、NTRU 格子のコンパクトさによって可能になります。FN-DSA は、非常に効率的な署名および検証手順も提供します。FN-DSA の主な潜在的な欠点は、そのアルゴリズムが自明ではないことと、他の格子スキームが効率は低いが均一分布乱数サンプリングをサポートしやすいガウス分布乱数サンプリングをサポートするために浮動小数点演算のサポートが必要であることです。
Implementers of FN-DSA need to be aware that FN-DSA signing is highly susceptible to side-channel attacks unless constant-time 64-bit floating-point operations are used. This requirement is extremely platform-dependent, as noted in NIST's report [NIST].
FN-DSA の実装者は、定数時間の 64 ビット浮動小数点演算が使用されない限り、FN-DSA 署名がサイドチャネル攻撃の影響を非常に受けやすいことを認識する必要があります。NIST のレポート [NIST] に記載されているように、この要件はプラットフォームに大きく依存します。
The performance characteristics of ML-DSA and FN-DSA may differ based on the specific implementation and hardware platform. Generally, ML-DSA is known for its relatively fast signature generation, while FN-DSA can provide more efficient signature verification. The choice may depend on whether the application requires more frequent signature generation or signature verification (see [LIBOQS]). For further clarity on the sizes and security levels, please refer to the tables in Sections 11 and 12.
ML-DSA と FN-DSA のパフォーマンス特性は、特定の実装とハードウェア プラットフォームによって異なる場合があります。一般に、ML-DSA は比較的高速な署名生成で知られていますが、FN-DSA はより効率的な署名検証を提供できます。どちらを選択するかは、アプリケーションがより頻繁な署名生成を必要とするか署名検証を必要とするかによって異なります ([LIBOQS] を参照)。サイズとセキュリティ レベルの詳細については、セクション 11 および 12 の表を参照してください。
SLH-DSA [SLH-DSA] utilizes the concept of stateless hash-based signatures, where each signature is unique and unrelated to any previous signature (as discussed in Section 8.2). This property eliminates the need for maintaining state information during the signing process. SLH-DSA was designed to sign up to 2^64 messages under a given key pair, and it offers three security levels. The parameters for each of the security levels were chosen to provide 128 bits of security, 192 bits of security, and 256 bits of security. SLH-DSA offers smaller public key sizes, larger signature sizes, slower signature generation, and slower verification when compared to ML-DSA and FN-DSA. SLH-DSA does not introduce a new hardness assumption beyond those inherent to the underlying hash functions. It builds upon established foundations in cryptography, making it a reliable and robust digital signature scheme for a post-quantum world.
SLH-DSA [SLH-DSA] はステートレスなハッシュベースの署名の概念を利用しており、各署名は一意であり、前の署名とは無関係です (セクション 8.2 で説明)。このプロパティにより、署名プロセス中に状態情報を維持する必要がなくなります。SLH-DSA は、特定のキー ペアで最大 2^64 メッセージに署名するように設計されており、3 つのセキュリティ レベルを提供します。各セキュリティ レベルのパラメータは、128 ビットのセキュリティ、192 ビットのセキュリティ、および 256 ビットのセキュリティを提供するように選択されました。SLH-DSA は、ML-DSA および FN-DSA と比較して、公開キーのサイズが小さく、署名のサイズが大きく、署名の生成と検証が遅くなります。SLH-DSA は、基礎となるハッシュ関数に固有のものを超える新しい硬度の仮定を導入しません。これは暗号化の確立された基盤の上に構築されており、ポスト量子の世界向けの信頼性が高く堅牢なデジタル署名スキームとなっています。
All of these algorithms (ML-DSA, FN-DSA, and SLH-DSA) include two signature modes: pure mode, where the entire content is signed directly, and pre-hash mode, where a digest of the content is signed.
これらのアルゴリズム (ML-DSA、FN-DSA、および SLH-DSA) にはすべて、コンテンツ全体が直接署名される純粋モードと、コンテンツのダイジェストが署名される事前ハッシュ モードの 2 つの署名モードが含まれています。
The eXtended Merkle Signature Scheme (XMSS) [RFC8391] and Hierarchical Signature Scheme (HSS) / Leighton-Micali Signature (LMS) [RFC8554] are stateful hash-based signature schemes, where the secret key state changes over time. In both schemes, reusing a secret key state compromises cryptographic security guarantees.
eXtended Merkle Signature Scheme (XMSS) [RFC8391] および Hierarchical Signature Scheme (HSS) / Leighton-Micali Signature (LMS) [RFC8554] はステートフルなハッシュベースの署名スキームであり、秘密鍵の状態は時間の経過とともに変化します。どちらの方式でも、秘密鍵の状態を再利用すると、暗号化セキュリティの保証が損なわれます。
XMSS and LMS can be used for signing a potentially large but fixed number of messages, and the number of signing operations depends upon the size of the tree. XMSS and LMS provide cryptographic digital signatures without relying on the conjectured hardness of mathematical problems, instead leveraging the properties of cryptographic hash functions. Multi-tree XMSS and LMS (i.e., XMSS-MT and HSS, respectively) use a hyper-tree-based hierarchical approach with a Merkle tree at each level of the hierarchy. [RFC8391] describes both single-tree and multi-tree variants of XMSS, while [RFC8554] describes the Leighton-Micali One-Time Signature (LM-OTS) system as well as the LMS and HSS N-time signature systems. Comparison of XMSS and LMS is discussed in Section 10 of [RFC8554].
XMSS と LMS は、潜在的に大量ではあるが固定数のメッセージに署名するために使用でき、署名操作の数はツリーのサイズによって異なります。XMSS と LMS は、数学的問題の推定難易度に依存せず、代わりに暗号ハッシュ関数の特性を利用して、暗号デジタル署名を提供します。マルチツリー XMSS および LMS (つまり、それぞれ XMSS-MT および HSS) は、階層の各レベルでマークル ツリーを使用するハイパーツリー ベースの階層アプローチを使用します。[RFC8391] では XMSS のシングルツリーとマルチツリーの両方のバリアントについて説明し、[RFC8554] では Leighton-Micali ワンタイム署名 (LM-OTS) システムと LMS および HSS N タイム署名システムについて説明しています。XMSS と LMS の比較は、[RFC8554] のセクション 10 で説明されています。
The number of tree layers in multi-tree XMSS and HSS provides a trade-off between signature size on the one side and key generation and signing speed on the other side. Increasing the number of layers reduces key generation time exponentially and signing time linearly at the cost of increasing the signature size linearly. HSS allows for customization of each subtree, whereas XMSS-MT does not, electing instead to use the same structure for each subtree.
マルチツリー XMSS および HSS のツリー層の数により、一方の署名サイズと他方の鍵の生成および署名速度の間のトレードオフが決まります。レイヤーの数を増やすと、署名サイズが直線的に増加するという代償を払って、鍵の生成時間が指数関数的に短縮され、署名時間が直線的に短縮されます。HSS では各サブツリーのカスタマイズが可能ですが、XMSS-MT ではカスタマイズができず、代わりに各サブツリーに同じ構造を使用することが選択されます。
Due to the complexities described above, XMSS and LMS are not suitable replacements for traditional signature schemes like RSA or ECDSA. Applications that expect a long lifetime of a signature, like firmware update or secure boot, are typical use cases where those schemes can be successfully applied.
上で説明した複雑さのため、XMSS と LMS は、RSA や ECDSA などの従来の署名スキームの代替として適していません。ファームウェアのアップデートやセキュア ブートなど、署名の有効期間が長いことが予想されるアプリケーションは、これらのスキームが正常に適用できる典型的な使用例です。
The LMS scheme is characterized by four distinct parameter sets: the underlying hash function (SHA2-256 or SHAKE-256), the length of the digest (24 or 32 bytes), the LMS tree height parameter that controls a maximal number of signatures that the private key can produce, and the width of the Winternitz coefficients (see [RFC8554], Section 4.1) that can be used to trade-off signing time for signature size. Parameters can be mixed, providing 80 possible parameterizations of the scheme.
LMS スキームは、4 つの異なるパラメータ セットによって特徴付けられます。基礎となるハッシュ関数 (SHA2-256 または SHAKE-256)、ダイジェストの長さ (24 または 32 バイト)、秘密鍵が生成できる署名の最大数を制御する LMS ツリー高さパラメータ、署名時間と署名サイズのトレードオフに使用できる Winternitz 係数の幅 ([RFC8554]、セクション 4.1 を参照) です。パラメータは混合でき、スキームの 80 通りのパラメータ化が可能です。
The public (PK) and private (SK) key size depends on the length of the digest (M). The signature size depends on the digest, the Winternitz parameter (W), the LMS tree height (H), and the length of the digest. The table below provides key and signature sizes for parameterization with the digest size M=32 of the scheme.
公開 (PK) キーと秘密 (SK) キーのサイズは、ダイジェスト (M) の長さによって異なります。署名のサイズは、ダイジェスト、Winternitz パラメーター (W)、LMS ツリーの高さ (H)、およびダイジェストの長さに依存します。以下の表は、スキームのダイジェスト サイズ M=32 でのパラメーター化のキーと署名のサイズを示しています。
+====+====+===+======+======+======+======+======+
| PK | SK | W | H=5 | H=10 | H=15 | H=20 | H=25 |
+====+====+===+======+======+======+======+======+
| 56 | 52 | 1 | 8684 | 8844 | 9004 | 9164 | 9324 |
+----+----+---+------+------+------+------+------+
| 56 | 52 | 2 | 4460 | 4620 | 4780 | 4940 | 5100 |
+----+----+---+------+------+------+------+------+
| 56 | 52 | 4 | 2348 | 2508 | 2668 | 2828 | 2988 |
+----+----+---+------+------+------+------+------+
| 56 | 52 | 8 | 1292 | 1452 | 1612 | 1772 | 1932 |
+----+----+---+------+------+------+------+------+
Table 1
Within the hash-then-sign paradigm, the message is hashed before signing it. By pre-hashing, the onus of resistance to existential forgeries becomes heavily reliant on the collision-resistance of the hash function in use. The hash-then-sign paradigm has the ability to improve application performance by reducing the size of signed messages that need to be transmitted between application and cryptographic module and making the signature size predictable and manageable. As a corollary, hashing remains mandatory even for short messages and assigns a further computational requirement onto the verifier. This makes the performance of hash-then-sign schemes more consistent, but not necessarily more efficient.
ハッシュしてから署名するパラダイムでは、メッセージは署名する前にハッシュされます。事前ハッシュにより、実存的偽造に対する抵抗の義務は、使用中のハッシュ関数の衝突耐性に大きく依存するようになります。ハッシュしてから署名するパラダイムには、アプリケーションと暗号化モジュール間で送信する必要がある署名付きメッセージのサイズを削減し、署名サイズを予測可能および管理可能にすることで、アプリケーションのパフォーマンスを向上させる機能があります。その結果として、ハッシュ化は短いメッセージであっても必須であり、検証者にさらなる計算要件を割り当てます。これにより、ハッシュして署名するスキームのパフォーマンスの一貫性が高まりますが、必ずしも効率が向上するとは限りません。
Using a hash function to produce a fixed-size digest of a message ensures that the signature is compatible with a wide range of systems and protocols, regardless of the specific message size or format. Crucially for hardware security modules, hash-then-sign also significantly reduces the amount of data that needs to be transmitted and processed by a Hardware Security Module (HSM). Consider scenarios such as a networked HSM located in a different data center from the calling application or a smart card connected over a USB interface. In these cases, streaming a message that is megabytes or gigabytes long can result in notable network latency, on-device signing delays, or even depletion of available on-device memory.
ハッシュ関数を使用してメッセージの固定サイズのダイジェストを生成すると、特定のメッセージ サイズや形式に関係なく、署名が幅広いシステムやプロトコルと互換性を持つことが保証されます。ハードウェア セキュリティ モジュールにとって重要なことは、ハッシュザ署名は、ハードウェア セキュリティ モジュール (HSM) によって送信および処理される必要があるデータの量も大幅に削減することです。呼び出し側アプリケーションとは別のデータセンターにあるネットワーク化された HSM や、USB インターフェイス経由で接続されたスマート カードなどのシナリオを考慮してください。このような場合、メガバイトまたはギガバイトの長さのメッセージをストリーミングすると、顕著なネットワーク遅延、デバイス上の署名遅延、さらには使用可能なデバイス上のメモリの枯渇が発生する可能性があります。
Note that the vast majority of Internet protocols that sign large messages already perform some form of content hashing at the protocol level, so this tends to be more of a concern with proprietary cryptographic protocols and protocols from non-IETF standards bodies. Protocols like TLS 1.3 and DNSSEC use the hash-then-sign paradigm. In TLS 1.3 [RFC8446] CertificateVerify messages, the content that is covered under the signature includes the transcript hash output (Section 4.4.1 of [RFC8446]) while DNSSEC [RFC4034] uses it to provide origin authentication and integrity assurance services for DNS data. Similarly, the Cryptographic Message Syntax (CMS) [RFC5652] includes a mandatory message digest step before invoking the signature algorithm.
大きなメッセージに署名するインターネット プロトコルの大部分は、すでにプロトコル レベルで何らかの形式のコンテンツ ハッシュを実行しているため、これは独自の暗号化プロトコルや非 IETF 標準化団体のプロトコルでより懸念される傾向にあることに注意してください。TLS 1.3 や DNSSEC などのプロトコルは、ハッシュして署名するパラダイムを使用します。TLS 1.3 [RFC8446] CertificateVerify メッセージでは、署名でカバーされるコンテンツにはトランスクリプト ハッシュ出力 ([RFC8446] のセクション 4.4.1) が含まれますが、DNSSEC [RFC4034] はこれを使用して、DNS データの発信元認証と整合性保証サービスを提供します。同様に、暗号メッセージ構文 (CMS) [RFC5652] には、署名アルゴリズムを呼び出す前に必須のメッセージ ダイジェスト ステップが含まれています。
In the case of ML-DSA, it internally incorporates the necessary hash operations as part of its signing algorithm. ML-DSA directly takes the original message, applies a hash function internally, and then uses the resulting hash value for the signature generation process. In the case of SLH-DSA, it internally performs randomized message compression using a keyed hash function that can process arbitrary length messages. In the case of FN-DSA, the SHAKE-256 hash function is used as part of the signature process to derive a digest of the message being signed.
ML-DSA の場合、署名アルゴリズムの一部として必要なハッシュ操作が内部的に組み込まれています。ML-DSA は、元のメッセージを直接取得し、内部でハッシュ関数を適用し、結果のハッシュ値を署名生成プロセスに使用します。SLH-DSA の場合、任意の長さのメッセージを処理できるキー付きハッシュ関数を使用して、内部でランダム化されたメッセージ圧縮を実行します。FN-DSA の場合、SHAKE-256 ハッシュ関数は署名プロセスの一部として使用され、署名されるメッセージのダイジェストを取得します。
Therefore, ML-DSA, FN-DSA, and SLH-DSA offer enhanced security over the traditional hash-then-sign paradigm because, by incorporating dynamic key material into the message digest, a pre-computed hash collision on the message to be signed no longer yields a signature forgery. Applications requiring the performance and bandwidth benefits of hash-then-sign may still pre-hash at the protocol level prior to invoking ML-DSA, FN-DSA, or SLH-DSA, but protocol designers should be aware that doing so reintroduces the weakness that hash collisions directly yield signature forgeries. Signing the full un-digested message is recommended where applications can tolerate it.
したがって、ML-DSA、FN-DSA、および SLH-DSA は、従来のハッシュしてから署名するパラダイムよりも強化されたセキュリティを提供します。これは、動的なキー素材をメッセージ ダイジェストに組み込むことにより、署名されるメッセージ上で事前に計算されたハッシュの衝突によって署名の偽造が生じなくなるためです。ハッシュ ザエン サインのパフォーマンスと帯域幅の利点を必要とするアプリケーションでは、ML-DSA、FN-DSA、または SLH-DSA を呼び出す前にプロトコル レベルで事前ハッシュを行うことができますが、プロトコル設計者は、そうすることで、ハッシュの衝突によって署名の偽造が直接生じるという弱点が再び持ち込まれることに注意する必要があります。アプリケーションが許容できる場合は、ダイジェストされていないメッセージ全体に署名することをお勧めします。
This information is a reprint of information provided in the NIST PQC project [NIST] as of the time this document is published. Table 2 denotes the five security levels provided by NIST for PQC algorithms. Neither NIST nor the IETF makes any specific recommendations about which security level to use. In general, protocols will include algorithm choices at multiple levels so that users can choose the level appropriate to their policies and data classification, similar to how organizations today choose which size of RSA key to use. The security levels are defined as requiring computational resources comparable to or greater than an attack on AES (128, 192, and 256) and SHA2/SHA3 algorithms, i.e., exhaustive key recovery for AES and optimal collision search for SHA2/SHA3.
この情報は、この文書の発行時点で NIST PQC プロジェクト [NIST] で提供されている情報の再版です。表 2 は、NIST が提供する PQC アルゴリズムの 5 つのセキュリティ レベルを示しています。NIST も IETF も、どのセキュリティ レベルを使用するかについて具体的な推奨を行っていません。一般に、プロトコルには複数のレベルでアルゴリズムの選択肢が含まれており、今日の組織が使用する RSA キーのサイズを選択する方法と同様に、ユーザーはポリシーやデータ分類に適したレベルを選択できます。セキュリティ レベルは、AES (128、192、256) および SHA2/SHA3 アルゴリズムに対する攻撃と同等以上の計算リソースを必要とするものとして定義されています。つまり、AES の徹底的なキー回復と SHA2/SHA3 の最適な衝突検索です。
+=============+=====================+===========================+
| PQ Security | AES/SHA(2/3) | PQC Algorithm |
| Level | hardness | |
+=============+=====================+===========================+
| 1 | AES-128 (exhaustive | ML-KEM-512, FN-DSA-512, |
| | key recovery) | SLH-DSA-SHA2/SHAKE-128f/s |
+-------------+---------------------+---------------------------+
| 2 | SHA-256/SHA3-256 | ML-DSA-44 |
| | (collision search) | |
+-------------+---------------------+---------------------------+
| 3 | AES-192 (exhaustive | ML-KEM-768, ML-DSA-65, |
| | key recovery) | SLH-DSA-SHA2/SHAKE-192f/s |
+-------------+---------------------+---------------------------+
| 4 | SHA-384/SHA3-384 | No algorithm tested at |
| | (collision search) | this level |
+-------------+---------------------+---------------------------+
| 5 | AES-256 (exhaustive | ML-KEM-1024, FN-DSA-1024, |
| | key recovery) | ML-DSA-87, SLH-DSA-SHA2/ |
| | | SHAKE-256f/s |
+-------------+---------------------+---------------------------+
Table 2
The SLH-DSA-x-yf/s "f/s" in the above table denotes whether SLH-DSA is using SHAKE or SHA-2 as an underlying hash function "x" and whether it is the fast (f) or small (s) version for "y" bit AES security level. Refer to [RFC9814] for further details on SLH-DSA algorithms.
上の表の SLH-DSA-x-yf/s 「f/s」は、SLH-DSA が基礎となるハッシュ関数「x」として SHAKE または SHA-2 を使用しているかどうか、および「y」ビット AES セキュリティ レベルの高速 (f) バージョンか小型 (s) バージョンかを示します。SLH-DSA アルゴリズムの詳細については、[RFC9814] を参照してください。
The following table compares the signature sizes for different SLH-DSA algorithm categories at equivalent security levels using the "simple" version. The categories include "f" for fast signature generation and "s" for smaller signature size and faster verification, although with slower signature generation. Both SHA-256 and SHAKE-256 parameterizations produce the same signature sizes and are therefore included together in the table.
次の表は、「シンプル」バージョンを使用した同等のセキュリティ レベルでの、さまざまな SLH-DSA アルゴリズム カテゴリの署名サイズを比較しています。カテゴリには、署名生成が高速であることを示す「f」と、署名の生成が遅いものの、署名サイズが小さく検証が高速であることを示す「s」が含まれます。SHA-256 と SHAKE-256 の両方のパラメータ化は同じ署名サイズを生成するため、表にまとめて含まれています。
+==========+===========================+========+=======+===========+
| PQ | Algorithm | Public |Private| Signature |
| Security | | key |key | size (in |
| Level | | size |size | bytes) |
| | | (in |(in | |
| | | bytes) |bytes) | |
+==========+===========================+========+=======+===========+
| 1 | SLH-DSA-{SHA2,SHAKE}-128f | 32 |64 | 17088 |
+----------+---------------------------+--------+-------+-----------+
| 1 | SLH-DSA-{SHA2,SHAKE}-128s | 32 |64 | 7856 |
+----------+---------------------------+--------+-------+-----------+
| 3 | SLH-DSA-{SHA2,SHAKE}-192f | 48 |96 | 35664 |
+----------+---------------------------+--------+-------+-----------+
| 3 | SLH-DSA-{SHA2,SHAKE}-192s | 48 |96 | 16224 |
+----------+---------------------------+--------+-------+-----------+
| 5 | SLH-DSA-{SHA2,SHAKE}-256f | 64 |128 | 49856 |
+----------+---------------------------+--------+-------+-----------+
| 5 | SLH-DSA-{SHA2,SHAKE}-256s | 64 |128 | 29792 |
+----------+---------------------------+--------+-------+-----------+
Table 3
The following table illustrates the impact of performance on different security levels in terms of private key sizes, public key sizes, and ciphertext/signature sizes.
次の表は、秘密キーのサイズ、公開キーのサイズ、暗号文/署名のサイズに関して、さまざまなセキュリティ レベルに対するパフォーマンスの影響を示しています。
+==========+=============+============+============+================+
| PQ | Algorithm | Public key | Private | Ciphertext/ |
| Security | | size (in | key size | signature |
| Level | | bytes) | (in bytes) | size (in |
| | | | | bytes) |
+==========+=============+============+============+================+
| 1 | ML-KEM-512 | 800 | 1632 | 768 |
+----------+-------------+------------+------------+----------------+
| 1 | FN-DSA-512 | 897 | 1281 | 666 |
+----------+-------------+------------+------------+----------------+
| 2 | ML-DSA-44 | 1312 | 2560 | 2420 |
+----------+-------------+------------+------------+----------------+
| 3 | ML-KEM-768 | 1184 | 2400 | 1088 |
+----------+-------------+------------+------------+----------------+
| 3 | ML-DSA-65 | 1952 | 4032 | 3309 |
+----------+-------------+------------+------------+----------------+
| 5 | FN-DSA-1024 | 1793 | 2305 | 1280 |
+----------+-------------+------------+------------+----------------+
| 5 | ML-KEM-1024 | 1568 | 3168 | 1588 |
+----------+-------------+------------+------------+----------------+
| 5 | ML-DSA-87 | 2592 | 4896 | 4627 |
+----------+-------------+------------+------------+----------------+
Table 4
This section provides two tables for comparison of different KEMs and signatures, respectively, in the traditional and post-quantum scenarios. These tables focus on the secret key sizes, public key sizes, and ciphertext/signature sizes for the PQC algorithms and their traditional counterparts of similar security levels.
このセクションでは、従来のシナリオとポスト量子シナリオにおけるさまざまな KEM と署名をそれぞれ比較するための 2 つの表を提供します。これらの表は、PQC アルゴリズムと同様のセキュリティ レベルの従来のアルゴリズムの秘密鍵のサイズ、公開鍵のサイズ、暗号文/署名のサイズに焦点を当てています。
The first table compares traditional and PQC KEMs in terms of security, public and private key sizes, and ciphertext sizes.
最初の表は、セキュリティ、公開キーと秘密キーのサイズ、および暗号文のサイズの観点から、従来の KEM と PQC KEM を比較しています。
+=============+=====================+========+=========+============+
| PQ Security | Algorithm | Public | Private | Ciphertext |
| Level | | key | key | size (in |
| | | size | size | bytes) |
| | | (in | (in | |
| | | bytes) | bytes) | |
+=============+=====================+========+=========+============+
| Traditional | P256_HKDF_SHA-256 | 65 | 32 | 65 |
+-------------+---------------------+--------+---------+------------+
| Traditional | P521_HKDF_SHA-512 | 133 | 66 | 133 |
+-------------+---------------------+--------+---------+------------+
| Traditional | X25519_HKDF_SHA-256 | 32 | 32 | 32 |
+-------------+---------------------+--------+---------+------------+
| 1 | ML-KEM-512 | 800 | 1632 | 768 |
+-------------+---------------------+--------+---------+------------+
| 3 | ML-KEM-768 | 1184 | 2400 | 1088 |
+-------------+---------------------+--------+---------+------------+
| 5 | ML-KEM-1024 | 1568 | 3168 | 1568 |
+-------------+---------------------+--------+---------+------------+
Table 5
The next table compares traditional and PQC signature schemes in terms of security, public, private key sizes, and signature sizes.
次の表は、セキュリティ、公開キー、秘密キーのサイズ、署名サイズの観点から、従来の署名スキームと PQC 署名スキームを比較しています。
+=============+=============+============+============+===========+
| PQ Security | Algorithm | Public key | Private | Signature |
| Level | | size (in | key size | size (in |
| | | bytes) | (in bytes) | bytes) |
+=============+=============+============+============+===========+
| Traditional | RSA2048 | 256 | 256 | 256 |
+-------------+-------------+------------+------------+-----------+
| Traditional | ECDSA-P256 | 64 | 32 | 64 |
+-------------+-------------+------------+------------+-----------+
| 1 | FN-DSA-512 | 897 | 1281 | 666 |
+-------------+-------------+------------+------------+-----------+
| 2 | ML-DSA-44 | 1312 | 2560 | 2420 |
+-------------+-------------+------------+------------+-----------+
| 3 | ML-DSA-65 | 1952 | 4032 | 3309 |
+-------------+-------------+------------+------------+-----------+
| 5 | FN-DSA-1024 | 1793 | 2305 | 1280 |
+-------------+-------------+------------+------------+-----------+
| 5 | ML-DSA-87 | 2592 | 4896 | 4627 |
+-------------+-------------+------------+------------+-----------+
Table 6
As is clear from the above table, PQC KEMs and signature schemes typically have significantly larger keys and ciphertexts/signatures than their traditional counterparts. These increased key and signatures sizes could introduce problems in protocols. As an example, the Internet Key Exchange Protocol Version 2 (IKEv2) uses UDP as the transport protocol for its messages. One challenge with integrating a PQC KEM into IKEv2 is that IKE fragmentation cannot be utilized in the initial IKE_SA_INIT exchange. To address this issue, [RFC9242] introduces a solution by defining a new exchange called the "Intermediate Exchange", which can be fragmented using the IKE fragmentation mechanism. [RFC9370] then uses this Intermediate Exchange to carry out the PQC key exchange after the initial IKEv2 exchange and before the IKE_AUTH exchange. Another example from Section 6.3.3 of [SP-1800-38C] shows that increased key and signature sizes cause protocol key exchange messages to span more network packets, which results in a higher total loss probability per packet. In lossy network conditions, this may increase the latency of the key exchange.
上の表から明らかなように、PQC KEM と署名スキームは通常、従来の対応するものよりも大幅に大きなキーと暗号文/署名を持っています。これらのキーと署名のサイズの増加により、プロトコルに問題が発生する可能性があります。一例として、インターネット キー交換プロトコル バージョン 2 (IKEv2) は、メッセージのトランスポート プロトコルとして UDP を使用します。PQC KEM を IKEv2 に統合する際の課題の 1 つは、最初の IKE_SA_INIT 交換で IKE フラグメンテーションを利用できないことです。この問題に対処するために、[RFC9242] では、IKE フラグメンテーション メカニズムを使用してフラグメント化できる、「中間交換」と呼ばれる新しい交換を定義することによる解決策を導入しています。[RFC9370] は、この中間交換を使用して、最初の IKEv2 交換の後、IKE_AUTH 交換の前に PQC 鍵交換を実行します。[SP-1800-38C] のセクション 6.3.3 の別の例では、鍵と署名のサイズが増加すると、プロトコル鍵交換メッセージがより多くのネットワーク パケットにまたがるようになり、その結果、パケットごとの合計損失確率が高くなることが示されています。損失の多いネットワーク状況では、これによりキー交換の遅延が増加する可能性があります。
The migration to PQC is unique in the history of modern digital cryptography in that neither the traditional algorithms nor the post-quantum algorithms are fully trusted to protect data for the required lifetimes. The traditional algorithms, such as RSA and ECDH, will fall to quantum cryptanalysis, while the post-quantum algorithms face uncertainty about the underlying mathematics, compliance issues, unknown vulnerabilities, and hardware and software implementations that have not had sufficient maturing time to rule out traditional cryptanalytic attacks and implementation bugs.
PQC への移行は、従来のアルゴリズムもポスト量子アルゴリズムも、必要な存続期間にわたってデータを保護するのに完全に信頼されていないという点で、現代のデジタル暗号化の歴史の中で独特です。RSA や ECDH などの従来のアルゴリズムは量子暗号解読に陥る一方、ポスト量子アルゴリズムは、基礎となる数学、コンプライアンス問題、未知の脆弱性、および従来の暗号解読攻撃や実装のバグを排除するのに十分な成熟時間がなかったハードウェアとソフトウェアの実装に関する不確実性に直面しています。
During the transition from traditional to post-quantum algorithms, there may be a desire or a requirement for protocols that use both algorithm types. [RFC9794] defines the terminology for PQ/T hybrid schemes.
従来のアルゴリズムからポスト量子アルゴリズムへの移行中に、両方のアルゴリズム タイプを使用するプロトコルが必要になる場合があります。[RFC9794] は、PQ/T ハイブリッド方式の用語を定義しています。
The PQ/T Hybrid Confidentiality property can be used to mitigate both "harvest now, decrypt now" and HNDL attacks described in Section 7. If the PQ portion were to have a flaw, the traditional (T) algorithm, which is secure against today's attackers, prevents immediate decryption ("harvest now, decrypt now"). If the T algorithm is broken in the future by CRQCs, the PQ portion, assuming it remains secure, prevents later decryption (i.e., HNDL). A hybrid construction therefore provides confidentiality as long as at least one component remains secure. Two types of hybrid key agreement schemes are discussed below.
PQ/T ハイブリッド機密性プロパティは、セクション 7 で説明されている「今すぐハーベスト、今復号化」攻撃と HNDL 攻撃の両方を軽減するために使用できます。PQ 部分に欠陥がある場合、今日の攻撃者に対して安全である従来の (T) アルゴリズムは、即時復号化 (「今ハーベスト、今すぐ復号化」) を防ぎます。将来、T アルゴリズムが CRQC によって破られた場合、PQ 部分は安全なままであると仮定して、後の復号化を防ぎます (つまり、HNDL)。したがって、ハイブリッド構造は、少なくとも 1 つのコンポーネントが安全である限り、機密性を提供します。2 つのタイプのハイブリッド鍵合意スキームについて以下で説明します。
Concatenated hybrid key agreement scheme:
連結されたハイブリッド鍵合意スキーム:
The final shared secret that will be used as an input of the key derivation function is the result of the concatenation of the secrets established with each key agreement scheme. For example, in [TLS-HYB-KEY-EXCH], the client uses the TLS supported groups extension to advertise support for a PQ/T hybrid scheme, and the server can select this group if it supports the scheme. The hybrid-aware client and server establish a hybrid secret by concatenating the two shared secrets, which is used as the shared secret in the existing TLS 1.3 key schedule.
鍵導出関数の入力として使用される最終的な共有秘密は、各鍵合意スキームで確立された秘密を連結した結果です。たとえば、[TLS-HYB-KEY-EXCH] では、クライアントは TLS サポート グループ拡張機能を使用して PQ/T ハイブリッド スキームのサポートをアドバタイズし、サーバーはスキームをサポートしている場合にこのグループを選択できます。ハイブリッド対応クライアントとサーバーは、2 つの共有シークレットを連結することによってハイブリッド シークレットを確立します。これは、既存の TLS 1.3 キー スケジュールの共有シークレットとして使用されます。
Cascaded hybrid key agreement scheme:
カスケード型ハイブリッド鍵合意スキーム:
The final shared secret is computed by applying as many iterations of the key derivation function as the number of key agreement schemes composing the hybrid key agreement scheme. For example, [RFC9370] extends IKEv2 to allow one or more PQC algorithms in addition to the traditional algorithm to derive the final IKE Security Association (SA) keys using the cascade method as explained in Section 2.2.2 of [RFC9370].
最終的な共有秘密は、ハイブリッド鍵合意スキームを構成する鍵合意スキームの数と同数の鍵導出関数の反復を適用することによって計算されます。たとえば、[RFC9370] は IKEv2 を拡張し、[RFC9370] のセクション 2.2.2 で説明されているように、カスケード方式を使用して最終的な IKE セキュリティ アソシエーション (SA) 鍵を導出する従来のアルゴリズムに加えて 1 つ以上の PQC アルゴリズムを許可します。
Various instantiations of these two types of hybrid key agreement schemes have been explored. One must be careful when selecting which hybrid scheme to use. The chosen scheme for protocols like TLS 1.3 [TLS-HYB-KEY-EXCH] has IND-CCA2 robustness. That is, IND-CCA2 security is guaranteed for the scheme as long as at least one of the component algorithms is IND-CCA2 secure.
これら 2 種類のハイブリッド鍵合意スキームのさまざまなインスタンス化が検討されています。どのハイブリッド方式を使用するかを選択するときは注意が必要です。TLS 1.3 [TLS-HYB-KEY-EXCH] などのプロトコルに選択されたスキームには、IND-CCA2 の堅牢性があります。つまり、コンポーネント アルゴリズムの少なくとも 1 つが IND-CCA2 セキュアである限り、そのスキームに対する IND-CCA2 セキュリティが保証されます。
The PQ/T hybrid authentication property provides resilience against catastrophic breaks or unforeseen vulnerabilities in PQC algorithms, allowing systems additional time to stabilize before migrating fully to pure PQ deployments.
PQ/T ハイブリッド認証プロパティは、PQC アルゴリズムの致命的な破損や予期せぬ脆弱性に対する回復力を提供し、純粋な PQ 導入に完全に移行する前に、システムが安定するまでの追加の時間を確保できます。
This property ensures authentication using a PQ/T hybrid scheme as long as at least one component algorithm remains secure. For example, a PQ/T hybrid certificate [ML-DSA-X.509] can be employed to facilitate a PQ/T hybrid authentication protocol. However, a PQ/T hybrid authentication protocol does not need to use a PQ/T hybrid certificate; separate certificates could be used for individual component algorithms [RFC9763]. When separate certificates are used, it may be possible for attackers to take them apart or put them together in unexpected ways, including enabling cross-protocol attacks. The exact risks this presents are highly dependent on the protocol and use case, so a full security analysis is needed. Best practices for ensuring that pairs of certificates are only used as intended are discussed in more detail in Sections 13.3.2 and 13.3.3 of this document.
このプロパティにより、少なくとも 1 つのコンポーネント アルゴリズムが安全である限り、PQ/T ハイブリッド スキームを使用した認証が保証されます。たとえば、PQ/T ハイブリッド証明書 [ML-DSA-X.509] を使用して、PQ/T ハイブリッド認証プロトコルを容易にすることができます。ただし、PQ/T ハイブリッド認証プロトコルでは、PQ/T ハイブリッド証明書を使用する必要はありません。個別の証明書は、個々のコンポーネントのアルゴリズムに使用できます [RFC9763]。個別の証明書が使用されている場合、攻撃者がそれらを分解したり、クロスプロトコル攻撃を可能にするなど、予期しない方法で組み合わせたりする可能性があります。これによって生じる正確なリスクはプロトコルとユースケースに大きく依存するため、完全なセキュリティ分析が必要です。証明書のペアが意図したとおりにのみ使用されるようにするためのベスト プラクティスについては、このドキュメントのセクション 13.3.2 および 13.3.3 で詳しく説明します。
The frequency and duration of system upgrades and the time when CRQCs will become widely available need to be weighed to determine whether and when to support the PQ/T Hybrid Authentication property.
PQ/T ハイブリッド認証プロパティをサポートするかどうか、いつサポートするかを決定するには、システム アップグレードの頻度と期間、および CRQC が広く利用可能になる時期を考慮する必要があります。
It is also possible to use more than two algorithms together in a hybrid scheme, with various methods for combining them. For post-quantum transition purposes, the combination of a post-quantum algorithm with a traditional algorithm is the most straightforward and recommended. The use of multiple post-quantum algorithms with different mathematical bases has also been considered. Combining algorithms in a way that requires both to be used together ensures stronger security, while combinations that do not require both will sacrifice security but offer other benefits like backwards compatibility and crypto agility. Including a traditional key alongside a post-quantum key often has minimal bandwidth impact.
ハイブリッド方式で 2 つ以上のアルゴリズムを一緒に使用し、それらを組み合わせるさまざまな方法を使用することもできます。ポスト量子移行の目的では、ポスト量子アルゴリズムと従来のアルゴリズムの組み合わせが最も簡単で推奨されます。異なる数学的基礎を持つ複数のポスト量子アルゴリズムの使用も検討されています。両方を一緒に使用する必要がある方法でアルゴリズムを組み合わせると、より強力なセキュリティが確保されます。一方、両方を必要としない組み合わせでは、セキュリティは犠牲になりますが、下位互換性や暗号化の俊敏性などの他の利点が得られます。多くの場合、ポスト量子キーと一緒に従来のキーを含めても、帯域幅への影響は最小限に抑えられます。
When combining keys in an "and" mode, it may make more sense to consider them to be a single composite key instead of two keys. This generally requires fewer changes to various components of PKI ecosystems, many of which are not prepared to deal with two keys or dual signatures. To those protocol- or application-layer parsers, a "composite" algorithm composed of two "component" algorithms is simply a new algorithm, and support for adding new algorithms generally already exists. Treating multiple "component" keys as a single "composite" key also has security advantages, such as preventing cross-protocol reuse of the individual component keys and guarantees about revoking or retiring all component keys together at the same time, especially if the composite is treated as a single object all the way down into the cryptographic module.
「and」モードでキーを組み合わせる場合、2 つのキーではなく 1 つの複合キーと考える方が合理的です。これには通常、PKI エコシステムのさまざまなコンポーネントに対する変更が少なくて済みますが、その多くは 2 つの鍵または二重署名を処理する準備ができていません。これらのプロトコル層またはアプリケーション層のパーサーにとって、2 つの「コンポーネント」アルゴリズムで構成される「複合」アルゴリズムは単なる新しいアルゴリズムであり、新しいアルゴリズムの追加のサポートは一般にすでに存在します。複数の「コンポーネント」キーを単一の「複合」キーとして扱うことには、セキュリティ上の利点もあります。たとえば、個々のコンポーネント キーのクロスプロトコル再利用を防止し、特に複合キーが暗号化モジュールに至るまで単一のオブジェクトとして扱われる場合、すべてのコンポーネント キーを同時に取り消したり破棄したりすることを保証します。
All that needs to be done is to standardize the formats of how the two keys from the two algorithms are combined into a single data structure and how the two resulting signatures or KEMs are combined into a single signature or KEM. The answer can be as simple as concatenation if the lengths are fixed or easily determined. At the time this document is published, security research is ongoing as to the security properties of concatenation-based composite signatures and KEMs versus more sophisticated signature and KEM combiners and protocol contexts in which those simpler combiners are sufficient.
必要なのは、2 つのアルゴリズムからの 2 つのキーを 1 つのデータ構造に結合する方法と、結果として得られる 2 つの署名または KEM を 1 つの署名または KEM に結合する方法の形式を標準化することだけです。長さが固定されているか、簡単に決定できる場合、答えは連結と同じくらい簡単です。このドキュメントの発行時点では、連結ベースの複合署名および KEM と、より洗練された署名および KEM コンバイナ、およびそれらの単純なコンバイナで十分なプロトコル コンテキストのセキュリティ特性に関するセキュリティ研究が進行中です。
One last consideration is the specific pairs of algorithms that can be combined. A recent trend in protocols is to only allow a small number of "known good" configurations that make sense, often referred to in cryptography as a "ciphersuite", instead of allowing arbitrary combinations of individual configuration choices that may interact in dangerous ways. The current consensus is that the same approach should be followed for combining cryptographic algorithms and that "known good" pairs should be explicitly listed ("explicit composite") instead of just allowing arbitrary combinations of any two cryptographic algorithms ("generic composite").
最後に考慮すべき点は、組み合わせることができるアルゴリズムの特定のペアです。最近のプロトコルの傾向は、危険な方法で相互作用する可能性のある個々の構成選択の任意の組み合わせを許可するのではなく、意味のある少数の「既知の良好な」構成のみを許可することです。これは、暗号学では「暗号スイート」と呼ばれることがよくあります。現在のコンセンサスは、暗号アルゴリズムを組み合わせる場合にも同じアプローチに従うべきであり、2 つの暗号アルゴリズムの任意の組み合わせ (「汎用複合」) を許可するのではなく、「既知の良好な」ペアを明示的にリストする (「明示的複合」) 必要があるということです。
The same considerations apply when using multiple certificates to transport a pair of related keys for the same subject. Exactly how two certificates should be managed in order to avoid some of the pitfalls mentioned above is still an active area of investigation. Using two certificates keeps the certificate tooling simple and straightforward, but in the end, this simply moves problems (i.e., problems with the requirement that both certificates be used as a pair, that two signatures that must be carried separately, and that both validate) to the certificate management layer, where addressing these concerns in a robust way can be difficult.
複数の証明書を使用して、同じサブジェクトの関連するキーのペアを転送する場合にも、同じ考慮事項が適用されます。上記のいくつかの落とし穴を回避するために 2 つの証明書をどのように管理すべきかについては、現在も活発に調査が行われています。2 つの証明書を使用すると、証明書ツールはシンプルかつ簡単になりますが、最終的には、問題 (つまり、両方の証明書をペアとして使用する必要がある、2 つの署名を別々に保持する必要がある、両方を検証するという要件に関する問題) が証明書管理層に移されるだけであり、これらの問題に堅牢な方法で対処することが困難になる場合があります。
At least one scheme has been proposed that allows the pair of certificates to exist as a single certificate when being issued and managed but dynamically split into individual certificates when needed (see [ENC-PAIR-CERTS]).
発行および管理される際には証明書のペアが単一の証明書として存在し、必要に応じて個々の証明書に動的に分割できるようにするスキームが少なくとも 1 つ提案されています ([ENC-PAIR-CERTS] を参照)。
An important security note, particularly when using hybrid signature keys, but also to a lesser extent hybrid KEM keys, is key reuse. In traditional cryptography, problems can occur with so-called "cross-protocol attacks" when the same key can be used for multiple protocols; for example, signing TLS handshakes and signing S/MIME emails. While it is not best practice to reuse keys within the same protocol, e.g., using the same key for multiple S/MIME certificates for the same user, it is not generally catastrophic for security. However, key reuse becomes a large security problem within hybrid schemes.
重要なセキュリティ上の注意事項は、特にハイブリッド署名キーを使用する場合、および程度は低いですがハイブリッド KEM キーを使用する場合、キーの再利用です。従来の暗号化では、同じキーを複数のプロトコルに使用できる場合、いわゆる「クロスプロトコル攻撃」で問題が発生する可能性があります。たとえば、TLS ハンドシェイクへの署名や S/MIME 電子メールへの署名などです。同じプロトコル内でキーを再利用すること（たとえば、同じユーザーの複数の S/MIME 証明書に同じキーを使用するなど）はベスト プラクティスではありませんが、一般にセキュリティにとって致命的な問題にはなりません。ただし、ハイブリッド方式ではキーの再利用がセキュリティ上の大きな問題になります。
Consider an {RSA, ML-DSA} hybrid key where the RSA key also appears within a single-algorithm certificate. In this case, an attacker could perform a "stripping attack" where they take some piece of data signed with the {RSA, ML-DSA} key, remove the ML-DSA signature, and present the data as if it was intended for the RSA only certificate. This leads to a set of security definitions called "non-separability properties", which refers to how well the signature scheme resists various complexities of downgrade/stripping attacks [HYBRID-SIG-SPECT]. Therefore, it is recommended that implementers either reuse the entire hybrid key as a whole or perform fresh key generation of all component keys per usage, and must not take an existing key and reuse it as a component of a hybrid key.
RSA キーが単一アルゴリズム証明書内にも存在する {RSA, ML-DSA} ハイブリッド キーを考えてみましょう。この場合、攻撃者は、{RSA, ML-DSA} キーで署名されたデータの一部を取得し、ML-DSA 署名を削除し、そのデータを RSA のみの証明書を対象としたものであるかのように提示する「ストリッピング攻撃」を実行する可能性があります。これは、「非分離性プロパティ」と呼ばれる一連のセキュリティ定義につながります。これは、署名スキームがダウングレード/ストリッピング攻撃のさまざまな複雑さにどれだけうまく抵抗できるかを指します [HYBRID-SIG-SPECT]。したがって、実装者は、ハイブリッド キー全体を全体として再利用するか、用途ごとにすべてのコンポーネント キーの新しいキー生成を実行することをお勧めします。また、既存のキーを取得してハイブリッド キーのコンポーネントとして再利用してはなりません。
Many aspects of hybrid cryptography are still under investigation. The LAMPS Working Group at IETF is actively exploring the security properties of these combinations, and future standards will reflect the evolving consensus on these issues.
ハイブリッド暗号の多くの側面はまだ調査中です。IETF の LAMPS ワーキング グループは、これらの組み合わせのセキュリティ特性を積極的に調査しており、将来の標準には、これらの問題に関する進化するコンセンサスが反映される予定です。
PQC algorithms generally have larger keys, ciphertext, and signature sizes than traditional public key algorithms. This has particular impact on constrained devices that operate with limited data rates. In the IoT space, these constraints have historically driven significant optimization efforts in the IETF (e.g., in the LAKE and CoRE Working Groups) to adapt security protocols to resource-constrained environments.
一般に、PQC アルゴリズムのキー、暗号文、署名のサイズは、従来の公開キー アルゴリズムよりも大きくなります。これは、制限されたデータ レートで動作する制約のあるデバイスに特に影響を与えます。IoT 空間では、これらの制約により、リソースに制約のある環境にセキュリティ プロトコルを適応させるために、IETF (LAKE ワーキング グループや CoRE ワーキング グループなど) での重要な最適化の取り組みが歴史的に推進されてきました。
As the transition to PQC progresses, these environments will face similar challenges. Larger message sizes can increase handshake latency, raise energy consumption, and require fragmentation logic. Work is ongoing in the IETF to study how PQC can be deployed in constrained devices (see [CONSTRAIN-DEV-PCQ]).
PQC への移行が進むにつれて、これらの環境も同様の課題に直面することになります。メッセージ サイズが大きくなると、ハンドシェイクの遅延が増加し、エネルギー消費が増加し、フラグメンテーション ロジックが必要になる可能性があります。IETF では、制約のあるデバイスに PQC を導入する方法を研究する作業が進行中です ([CONSTRAIN-DEV-PCQ] を参照)。
Traditional cryptanalysis exploits weaknesses in algorithm design, mathematical vulnerabilities, or implementation flaws that are exploitable with classical (i.e., non-quantum) hardware, whereas quantum cryptanalysis harnesses the power of CRQCs to solve specific mathematical problems more efficiently. Quantum side-channel attacks are another form of quantum cryptanalysis. In such attacks, a device under threat is directly connected to a quantum computer, which then injects entangled or superimposed data streams to exploit hardware that lacks protection against quantum side channels. Both pose threats to the security of cryptographic algorithms, including those used in PQC. It is crucial to develop and adopt new cryptographic algorithms resilient against these threats to ensure long-term security in the face of advancing cryptanalysis techniques.
従来の暗号解読は、古典的な (つまり、非量子) ハードウェアで悪用可能なアルゴリズム設計の弱点、数学的脆弱性、または実装の欠陥を悪用しますが、量子暗号解読は CRQC の力を利用して、特定の数学的問題をより効率的に解決します。量子サイドチャネル攻撃は、量子暗号解析の別の形式です。このような攻撃では、脅威にさらされているデバイスが量子コンピューターに直接接続され、量子コンピューターが量子サイド チャネルに対する保護が欠けているハードウェアを悪用するために、もつれたり重ね合わされたデータ ストリームを注入します。どちらも、PQC で使用される暗号アルゴリズムを含む暗号アルゴリズムのセキュリティに脅威をもたらします。進歩する暗号解析技術に直面して長期的なセキュリティを確保するには、これらの脅威に対して回復力のある新しい暗号アルゴリズムを開発および採用することが重要です。
Recent attacks on the side-channel implementations using deep learning-based power analysis have also shown that one needs to be cautious while implementing the required PQC algorithms in hardware. Two of the most recent works include one attack on ML-KEM [KyberSide] and one attack on Saber [SaberSide]. An evolving threat landscape points to the fact that lattice-based cryptography is indeed more vulnerable to side-channel attacks as in [SideCh] and [LatticeSide]. Consequently, some mitigation techniques for side-channel attacks have been proposed; see [Mitigate1], [Mitigate2], and [Mitigate3].
深層学習ベースの電力分析を使用したサイドチャネル実装に対する最近の攻撃も、必要な PQC アルゴリズムをハードウェアに実装する際には注意が必要であることを示しています。最新の 2 つの作業には、ML-KEM [KyberSide] に対する 1 件の攻撃と、Sabre [SaberSide] に対する 1 件の攻撃が含まれます。進化する脅威の状況は、格子ベースの暗号化が実際に [SideCh] や [LatticeSide] のようなサイドチャネル攻撃に対してより脆弱であるという事実を示しています。その結果、サイドチャネル攻撃に対するいくつかの軽減技術が提案されています。[軽減1]、[軽減2]、および[軽減3]を参照してください。
Cryptographic agility is recommended for both traditional and quantum cryptanalysis as it enables organizations to adapt to emerging threats, adopt stronger algorithms, comply with standards, and plan for long-term security in the face of evolving cryptanalytic techniques and the advent of CRQCs.
暗号の俊敏性は、進化する暗号解読技術と CRQC の出現に直面しても、組織が新たな脅威に適応し、より強力なアルゴリズムを採用し、標準に準拠し、長期的なセキュリティを計画できるようになるため、従来の暗号解読と量子暗号解読の両方に推奨されます。
Several PQC schemes are available that need to be tested; cryptography experts around the world are pushing for the best possible solutions, and the first standards that will ease the introduction of PQC are being prepared. This is of paramount importance and is a call for imminent action for organizations, bodies, and enterprises to start evaluating their cryptographic agility, assess the complexity of implementing PQC into their products, processes, and systems, and develop a migration plan that achieves their security goals to the best possible extent.
テストする必要があるいくつかの PQC スキームが利用可能です。世界中の暗号化専門家が可能な限り最良のソリューションを追求しており、PQC の導入を容易にする最初の標準が準備されています。これは非常に重要であり、組織、団体、企業が暗号化の機敏性の評価を開始し、製品、プロセス、システムへの PQC 実装の複雑さを評価し、セキュリティ目標を可能な限り達成する移行計画を策定するための早急な行動が求められています。
An important and often overlooked step in achieving cryptographic agility is maintaining a cryptographic inventory. Modern software stacks incorporate cryptography in numerous places, making it challenging to identify all instances. Therefore, cryptographic agility and inventory management take two major forms. First, application developers responsible for software maintenance should actively search for instances of hard-coded cryptographic algorithms within applications. When possible, they should design the choice of algorithm to be dynamic, based on application configuration. Second, administrators, policy officers, and compliance teams should take note of any instances where an application exposes cryptographic configurations. These instances should be managed through either organization-wide written cryptographic policies or automated cryptographic policy systems.
暗号化の俊敏性を実現するための重要かつ見落とされがちなステップは、暗号化インベントリを維持することです。最新のソフトウェア スタックにはさまざまな場所に暗号化が組み込まれているため、すべてのインスタンスを識別することが困難になっています。したがって、暗号化の俊敏性と在庫管理には 2 つの主要な形式があります。まず、ソフトウェアのメンテナンスを担当するアプリケーション開発者は、アプリケーション内でハードコードされた暗号アルゴリズムのインスタンスを積極的に検索する必要があります。可能であれば、アプリケーションの構成に基づいてアルゴリズムの選択が動的になるように設計する必要があります。次に、管理者、ポリシー担当者、およびコンプライアンス チームは、アプリケーションが暗号化構成を公開するインスタンスに注意する必要があります。これらのインスタンスは、組織全体で作成された暗号化ポリシーまたは自動化された暗号化ポリシー システムを通じて管理する必要があります。
Numerous commercial solutions are available for detecting hard-coded cryptographic algorithms in source code and compiled binaries, as well as providing cryptographic policy management control planes for enterprise and production environments.
ソース コードおよびコンパイルされたバイナリ内のハードコーディングされた暗号アルゴリズムを検出したり、エンタープライズ環境や実稼働環境に暗号ポリシー管理コントロール プレーンを提供したりするための商用ソリューションが数多く用意されています。
Another potential application of hybrid schemes bears mentioning, even though it is not directly related to PQC: using hybrids to navigate inter-jurisdictional cryptographic connections. Traditional cryptography is already fragmented by jurisdiction. Consider that while most jurisdictions support ECDH, those in the United States will prefer the NIST curves while those in Germany will prefer the Brainpool curves. China, Russia, and other jurisdictions have their own national cryptography standards. This situation of fragmented global cryptography standards is unlikely to improve with PQC. If "and" mode hybrid schemes become standardized for the reasons mentioned above, then one could imagine leveraging them to create ciphersuites in which a single cryptographic operation simultaneously satisfies the cryptographic requirements of both endpoints.
PQC とは直接関係ありませんが、ハイブリッド スキームのもう 1 つの潜在的な応用例として、ハイブリッドを使用して管轄区域間の暗号化接続をナビゲートすることが挙げられます。従来の暗号化はすでに管轄区域によって細分化されています。ほとんどの法域は ECDH をサポートしていますが、米国の法域は NIST 曲線を好み、ドイツの法域は Brainpool 曲線を好むことを考慮してください。中国、ロシア、およびその他の管轄区域には、独自の国家暗号化標準があります。世界的な暗号化標準が断片化しているこの状況は、PQC によって改善される可能性は低いです。上記の理由で「and」モードのハイブリッド方式が標準化されると、それらを活用して、単一の暗号化操作が両方のエンドポイントの暗号化要件を同時に満たす暗号スイートを作成することが想像できます。
Post-quantum algorithms selected for standardization are relatively new and have not been subject to the same depth of study as traditional algorithms. PQC implementations will also be new and therefore more likely to contain implementation bugs than the battle-tested crypto implementations that are relied on today. In addition, certain deployments may need to retain traditional algorithms due to regulatory constraints, e.g., FIPS [SP-800-56C] or Payment Card Industry (PCI) compliance [PCI]. Hybrid key exchange is recommended to enhance security against the HNDL attack. Additionally, hybrid signatures provide for time to react in the case of the announcement of a devastating attack against any one algorithm, while not fully abandoning traditional cryptosystems.
標準化のために選択されたポスト量子アルゴリズムは比較的新しく、従来のアルゴリズムほど深く研究されていません。PQC の実装も新しいものとなるため、現在信頼されている厳しいテストが行われた暗号実装よりも実装のバグが含まれる可能性が高くなります。さらに、特定の展開では、FIPS [SP-800-56C] や Payment Card Industry (PCI) コンプライアンス [PCI] などの規制上の制約により、従来のアルゴリズムを保持する必要がある場合があります。HNDL 攻撃に対するセキュリティを強化するには、ハイブリッド キー交換が推奨されます。さらに、ハイブリッド署名は、従来の暗号システムを完全に放棄することなく、いずれか 1 つのアルゴリズムに対する壊滅的な攻撃が発表された場合に対応する時間を提供します。
Hybrid key exchange performs both a classical and a post-quantum key exchange in parallel. It provides security redundancy against potential weaknesses in PQC algorithms, allows for a gradual transition of trust in PQC algorithms, and, in backward-compatible designs, enables gradual adoption without breaking compatibility with existing systems. For instance, in TLS 1.3, a hybrid key exchange can combine a widely supported classical algorithm, such as X25519, with a post-quantum algorithm like ML-KEM. This allows legacy clients to continue using the classical algorithm while enabling upgraded clients to proceed with hybrid key exchange. In contrast, overhead-spreading hybrid designs focus on reducing the PQ overhead. For example, approaches like those described in [PQ-MLS] amortize PQ costs by selectively applying PQ updates in key exchange processes, allowing systems to balance security and efficiency. This strategy ensures a post-quantum secure channel while keeping the overhead manageable, making it particularly suitable for constrained environments.
ハイブリッド鍵交換は、古典的な鍵交換とポスト量子鍵交換の両方を並行して実行します。これにより、PQC アルゴリズムの潜在的な弱点に対するセキュリティの冗長性が提供され、PQC アルゴリズムの信頼性の段階的な移行が可能になり、下位互換性のある設計では、既存のシステムとの互換性を損なうことなく段階的な導入が可能になります。たとえば、TLS 1.3 では、ハイブリッド キー交換により、X25519 などの広くサポートされている古典的なアルゴリズムと、ML-KEM などのポスト量子アルゴリズムを組み合わせることができます。これにより、レガシー クライアントは従来のアルゴリズムを引き続き使用できる一方で、アップグレードされたクライアントはハイブリッド キー交換を続行できるようになります。対照的に、オーバーヘッド分散ハイブリッド設計は、PQ オーバーヘッドの削減に重点を置いています。たとえば、[PQ-MLS] で説明されているようなアプローチでは、鍵交換プロセスで PQ アップデートを選択的に適用することで PQ コストを償却し、システムがセキュリティと効率のバランスを取れるようにします。この戦略は、オーバーヘッドを管理しやすく保ちながら量子後の安全なチャネルを確保するため、制約のある環境に特に適しています。
While some hybrid key exchange options introduce additional computational and bandwidth overhead, the impact of traditional key exchange algorithms (e.g., key size) is typically small, helping to keep the overall increase in resource usage manageable for most systems. In highly constrained environments, however, those hybrid key exchange protocols may be impractical due to their higher resource requirements compared to pure post-quantum or traditional key exchange approaches. However, some hybrid key exchange designs distribute the PQC overhead, making them more suitable for constrained environments. The choice of hybrid key exchange design depends on the specific system requirements and use case, so the appropriate approach may vary.
一部のハイブリッド鍵交換オプションでは、追加の計算量と帯域幅のオーバーヘッドが発生しますが、従来の鍵交換アルゴリズム (鍵サイズなど) の影響は通常は小さく、ほとんどのシステムでリソース使用量の全体的な増加を管理可能な状態に保つのに役立ちます。ただし、高度に制約された環境では、これらのハイブリッド鍵交換プロトコルは、純粋な量子後または従来の鍵交換アプローチと比較してリソース要件が高くなるため、実用的ではない可能性があります。ただし、一部のハイブリッド キー交換設計は PQC オーバーヘッドを分散し、制約のある環境により適したものにしています。ハイブリッド鍵交換設計の選択は、特定のシステム要件とユースケースに依存するため、適切なアプローチは異なる場合があります。
The ciphertext generated by a KEM is not necessarily directly linked to the shared secret it produces. KEMs allow for multiple ciphertexts to encapsulate the same shared secret, which enables flexibility in key management without enforcing a strict one-to-one correspondence between ciphertexts and shared secrets. This allows for secret reuse across different recipients, sessions, or operational contexts without the need for new secrets for each use, simplifying key distribution and reducing computational overhead. In contrast, cryptographic schemes like Diffie-Hellman inherently link the public key to the derived shared secret, meaning any change in the public key results in a different shared secret.
KEM によって生成される暗号文は、KEM が生成する共有秘密に必ずしも直接リンクされているわけではありません。KEM を使用すると、複数の暗号文で同じ共有秘密をカプセル化できるため、暗号文と共有秘密の間の厳密な 1 対 1 対応を強制することなく、鍵管理を柔軟に行うことができます。これにより、使用のたびに新しいシークレットを必要とせずに、さまざまな受信者、セッション、または運用コンテキスト間でシークレットを再利用できるため、キーの配布が簡素化され、計算オーバーヘッドが削減されます。対照的に、Diffie-Hellman のような暗号スキームは本質的に公開キーを派生共有秘密にリンクします。つまり、公開キーを変更すると、別の共有秘密が生成されます。
This document has no IANA actions.
この文書には IANA のアクションはありません。
A good book on modern cryptography is "Serious Cryptography, 2nd Edition" by Jean-Philippe Aumasson [Serious-Crypt].
現代の暗号化に関する良い本は、Jean-Philippe Aumasson 著の『Serious Cryptography, 2nd Edition』[Serious-Crypt] です。
The Open Quantum Safe (OQS) Project [OQS] is an open-source project that aims to support the transition to quantum-resistant cryptography.
Open Quantum Safe (OQS) プロジェクト [OQS] は、耐量子暗号への移行をサポートすることを目的としたオープンソース プロジェクトです。
The IETF's PQUIP Working Group [PQUIP-WG] maintains a list of PQC-related protocol work within the IETF.
IETF の PQUIP ワーキング グループ [PQUIP-WG] は、IETF 内での PQC 関連のプロトコル作業のリストを管理しています。
[ClassicMcEliece]
"Classic McEliece", <https://classic.mceliece.org/>.
[FN-DSA] "FALCON: Fast Fourier lattice-based compact signatures
over NTRU", <https://falcon-sign.info/>.
[FrodoKEM] "FrodoKEM", <https://frodokem.org/>.
[Grovers] Grover, L. K., "A fast quantum mechanical algorithm for
database search", STOC '96: Proceedings of the twenty-
eighth annual ACM symposium on Theory of Computing, pp.
212-219, DOI 10.1145/237814.237866, 1 July 1996,
<https://dl.acm.org/doi/10.1145/237814.237866>.
[ML-DSA] NIST, "Module-Lattice-Based Digital Signature Standard",
NIST FIPS 204, DOI 10.6028/NIST.FIPS.204, August 2024,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.204.pdf>.
[ML-KEM] NIST, "Module-Lattice-Based Key-Encapsulation Mechanism
Standard", NIST FIPS 203, DOI 10.6028/nist.fips.203,
August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.203.pdf>.
[NTRU] "NTRU", <https://ntru.org/index.shtml>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011,
<https://www.rfc-editor.org/info/rfc6090>.
[RFC8235] Hao, F., Ed., "Schnorr Non-interactive Zero-Knowledge
Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017,
<https://www.rfc-editor.org/info/rfc8235>.
[RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A.
Mohaisen, "XMSS: eXtended Merkle Signature Scheme",
RFC 8391, DOI 10.17487/RFC8391, May 2018,
<https://www.rfc-editor.org/info/rfc8391>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8554] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali
Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554,
April 2019, <https://www.rfc-editor.org/info/rfc8554>.
[RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
February 2022, <https://www.rfc-editor.org/info/rfc9180>.
[RFC9242] Smyslov, V., "Intermediate Exchange in the Internet Key
Exchange Protocol Version 2 (IKEv2)", RFC 9242,
DOI 10.17487/RFC9242, May 2022,
<https://www.rfc-editor.org/info/rfc9242>.
[RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van
Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
Key Exchanges in the Internet Key Exchange Protocol
Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May
2023, <https://www.rfc-editor.org/info/rfc9370>.
[RFC9881] Massimo, J., Kampanakis, P., Turner, S., and B. E.
Westerbaan, "Internet X.509 Public Key Infrastructure --
Algorithm Identifiers for the Module-Lattice-Based Digital
Signature Algorithm (ML-DSA)", RFC 9881,
DOI 10.17487/RFC9881, October 2025,
<https://www.rfc-editor.org/info/rfc9881>.
[RSA] Rivest, R. L., Shamir, A., and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key
Cryptosystems", Communications of the ACM, vol. 21, no. 2,
pp. 120-126, DOI 10.1145/359340.359342, February 1978,
<https://dl.acm.org/doi/pdf/10.1145/359340.359342>.
[Shors] Shor, P., "Polynomial-Time Algorithms for Prime
Factorization and Discrete Logarithms on a Quantum
Computer", arXiv:quant-ph/9508027v2, 25 January 1996,
<https://arxiv.org/pdf/quant-ph/9508027>.
[SLH-DSA] NIST, "Stateless Hash-Based Digital Signature Standard",
NIST FIPS 205, DOI 10.6028/NIST.FIPS.205, August 2024,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.205.pdf>.
[AddSig] NIST, "Post-Quantum Cryptography: Additional Digital
Signature Schemes", <https://csrc.nist.gov/Projects/pqc-
dig-sig/standardization>.
[ANSSI] ANSSI, "ANSSI views on the Post-Quantum Cryptography
transition (2023 follow up)", 21 December 2023,
<https://cyber.gouv.fr/sites/default/files/document/follow
_up_position_paper_on_post_quantum_cryptography.pdf>.
[BBS-SIG-SCHEME]
Looker, T., Kalos, V., Whitehead, A., and M. Lodder, "The
BBS Signature Scheme", Work in Progress, Internet-Draft,
draft-irtf-cfrg-bbs-signatures-10, 8 January 2026,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
bbs-signatures-10>.
[BHK09] Bellare, M., Hofheinz, D., and E. Kiltz, "Subtleties in
the Definition of IND-CCA: When and How Should Challenge-
Decryption be Disallowed?", Cryptology ePrint Archive,
Paper 2009/418, 2009, <https://eprint.iacr.org/2009/418>.
[BIKE] "BIKE", <https://bikesuite.org/>.
[BPQS] Chalkias, K., Brown, J., Hearn, M., Lillehagen, T., Nitto,
I., and T. Schroeter, "Blockchained Post-Quantum
Signatures", Cryptology ePrint Archive, Paper 2018/658,
<https://eprint.iacr.org/2018/658>.
[BSI-PQC] BSI, "Quantum-safe cryptography - fundamentals, current
developments and recommendations", 18 May 2022,
<https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/
Publications/Brochure/quantum-safe-
cryptography.html?nn=916626>.
[Cloudflare]
Westerbaan, B., "NIST's pleasant post-quantum surprise",
Cloudflare Blog, 8 July 2022,
<https://blog.cloudflare.com/nist-post-quantum-surprise/>.
[CNSA2-0] NSA, "Announcing the Commercial National Security
Algorithm Suite 2.0", September 2022,
<https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/
CSA_CNSA_2.0_ALGORITHMS.PDF>.
[CONSTRAIN-DEV-PCQ]
Reddy.K, T., Wing, D., Salter, B., and K. Kwiatkowski,
"Adapting Constrained Devices for Post-Quantum
Cryptography", Work in Progress, Internet-Draft, draft-
ietf-pquip-pqc-hsm-constrained-05, 1 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
pqc-hsm-constrained-05>.
[CRQCThreat]
Jaques, S., "Landscape of Quantum Computing",
<https://sam-jaques.appspot.com/quantum_landscape_2024>.
[CS01] Cramer, R. and V. Shoup, "Design and Analysis of Practical
Public-Key Encryption Schemes Secure against Adaptive
Chosen Ciphertext Attack", Cryptology ePrint Archive,
Paper 2001/108, 2001, <https://eprint.iacr.org/2001/108>.
[ENC-PAIR-CERTS]
Bonnell, C., Gray, J., Hook, D., Okubo, T., and M.
Ounsworth, "A Mechanism for Encoding Differences in Paired
Certificates", Work in Progress, Internet-Draft, draft-
bonnell-lamps-chameleon-certs-07, 18 October 2025,
<https://datatracker.ietf.org/doc/html/draft-bonnell-
lamps-chameleon-certs-07>.
[GMR88] Goldwasser, S., Micali, S., and R. L. Rivest, "A digital
signature scheme secure against adaptive chosen-message
attacks", SIAM Journal on Computing, vol. 17, no. 2, pp.
281-308, DOI 10.1137/0217017, April 1988,
<https://people.csail.mit.edu/silvio/
Selected%20Scientific%20Papers/Digital%20Signatures/
A_Digital_Signature_Scheme_Secure_Against_Adaptive_Chosen-
Message_Attack.pdf>.
[Grover-Search]
Zalka, C., "Grover's quantum searching algorithm is
optimal", Physical Review A, vol. 60, no. 4, pp.
2746-2751, DOI 10.1103/PhysRevA.60.2746, October 1999,
<https://link.aps.org/doi/10.1103/PhysRevA.60.2746>.
[HQC] "HQC", <http://pqc-hqc.org/>.
[HYBRID-SIG-SPECT]
Bindel, N., Hale, B., Connolly, D., and F. D, "Hybrid
signature spectrums", Work in Progress, Internet-Draft,
draft-ietf-pquip-hybrid-signature-spectrums-07, 20 June
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
pquip-hybrid-signature-spectrums-07>.
[KEEPINGUP]
Cremers, C., Dax, A., and N. Medinger, "Keeping Up with
the KEMs: Stronger Security Notions for KEMs and automated
analysis of KEM-based protocols", Cryptology ePrint
Archive, Paper 2023/1933, 2023,
<https://eprint.iacr.org/2023/1933>.
[KEM-COMBINER]
Ounsworth, M., Wussler, A., and S. Kousidis, "Combiner
function for hybrid key encapsulation mechanisms (Hybrid
KEMs)", Work in Progress, Internet-Draft, draft-ounsworth-
cfrg-kem-combiners-05, 31 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ounsworth-
cfrg-kem-combiners-05>.
[KyberSide]
Ji, Y., Wang, R., Ngo, K., Dubrova, E., and L. Backlund,
"A Side-Channel Attack on a Hardware Implementation of
CRYSTALS-Kyber", Cryptology ePrint Archive, Paper
2022/1452, 2022, <https://eprint.iacr.org/2022/1452>.
[LattFail1]
D'Anvers, J., Guo, Q., Johansson, T., Nilsson, A.,
Vercauteren, F., and I. Verbauwhede, "Decryption Failure
Attacks on IND-CCA Secure Lattice-Based Schemes", Public-
Key Cryptography - PKC 2019, Lecture Notes in Computer
Science, vol. 11443, pp. 565-598,
DOI 10.1007/978-3-030-17259-6_19, 6 April 2019,
<https://link.springer.com/
chapter/10.1007/978-3-030-17259-6_19>.
[LattFail2]
D'Anvers, J., Rossi, M., and F. Virdia, "(One) Failure Is
Not an Option: Bootstrapping the Search for Failures in
Lattice-Based Encryption Schemes", Advances in Cryptology
- EUROCRYPT 2020, Lecture Notes in Computer Science, vol.
12107, pp. 3-33, DOI 10.1007/978-3-030-45727-3_1, 1 May
2020, <https://link.springer.com/
chapter/10.1007/978-3-030-45727-3_1>.
[LatticeSide]
Ravi, P., Roy, S. S., Chattopadhyay, A., and S. Bhasin,
"Generic Side-channel attacks on CCA-secure lattice-based
PKE and KEM schemes", Cryptology ePrint Archive, Paper
2019/948, 2019, <https://eprint.iacr.org/2019/948>.
[LIBOQS] "LibOQS - Open Quantum Safe", commit 97f6b86, November
2025, <https://github.com/open-quantum-safe/liboqs>.
[Lyu09] Lyubashevsky, V., "Fiat-Shamir With Aborts: Applications
to Lattice and Factoring-Based Signatures", ASIACRYPT
2009, <https://www.iacr.org/archive/
asiacrypt2009/59120596/59120596.pdf>.
[Mitigate1]
Hoffmann, C., Libert, B., Momin, C., Peters, T., and F.
Standaert, "POLKA: Towards Leakage-Resistant Post-Quantum
CCA-Secure Public Key Encryption", Cryptology ePrint
Archive, Paper 2022/873, 2022,
<https://eprint.iacr.org/2022/873>.
[Mitigate2]
Tsai, T., Huang, S., Tseng, Y., Chuang, Y., and Y. Hung,
"Leakage-Resilient Certificate-Based Authenticated Key
Exchange Protocol", IEEE Open Journal of the Computer
Society, vol. 3, pp. 137-148,
DOI 10.1109/OJCS.2022.3198073, 2022,
<https://ieeexplore.ieee.org/document/9855226>.
[Mitigate3]
Azouaoui, M., Kuzovkova, Y., Schneider, T., and C. V.
Vredendaal, "Post-Quantum Authenticated Encryption against
Chosen-Ciphertext Side-Channel Attacks", Cryptology ePrint
Archive, Paper 2022/916, 2022,
<https://eprint.iacr.org/2022/916>.
[ML-DSA-X.509]
Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S.
Fluhrer, "Composite Module-Lattice-Based Digital Signature
Algorithm (ML-DSA) for use in X.509 Public Key
Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-lamps-pq-composite-sigs-19, 21 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-19>.
[NIST] NIST, "Post-Quantum Cryptography Standardization",
<https://csrc.nist.gov/projects/post-quantum-cryptography/
post-quantum-cryptography-standardization>.
[NISTFINAL]
NIST, "NIST Releases First 3 Finalized Post-Quantum
Encryption Standards", 13 August 2024,
<https://www.nist.gov/news-events/news/2024/08/nist-
releases-first-3-finalized-post-quantum-encryption-
standards>.
[OQS] "Open Quantum Safe Project",
<https://openquantumsafe.org/>.
[PCI] PCI Security Standards Council, "Payment Card Industry
Data Security Standard", PCI DSS: v4.0.1, <https://docs-
prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-
v4_0_1.pdf>.
[PQ-HPKE] Barnes, R. and D. Connolly, "Post-Quantum and Post-
Quantum/Traditional Hybrid Algorithms for HPKE", Work in
Progress, Internet-Draft, draft-ietf-hpke-pq-04, 2 March
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
hpke-pq-04>.
[PQ-KEM] Connolly, D., Barnes, R., and P. Grubbs, "Hybrid PQ/T Key
Encapsulation Mechanisms", Work in Progress, Internet-
Draft, draft-irtf-cfrg-hybrid-kems-11, 7 May 2026,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
hybrid-kems-11>.
[PQ-MLS] Tian, X., Hale, B., Mularczyk, M., and J. Alwen,
"Amortized PQ MLS Combiner", Work in Progress, Internet-
Draft, draft-ietf-mls-combiner-02, 22 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-mls-
combiner-02>.
[PQCAPI] NIST, "PQC - API notes",
<https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-
Cryptography/documents/example-files/api-notes.pdf>.
[PQRSA] Bernstein, D. J., Heninger, N., Lou, P., and L. Valenta,
"Post-quantum RSA", 19 April 2017,
<https://cr.yp.to/papers/pqrsa-20170419.pdf>.
[PQUIP-WG] IETF, "Post-Quantum Use In Protocols (pquip)",
<https://datatracker.ietf.org/group/pquip/documents/>.
[QC-DNS] Hoffman, P., "Quantum Computing and the DNS", ICANN Office
of the Chief Technology Officer, OCTO-031v2, 22 April
2024, <https://www.icann.org/octo-031-en.pdf>.
[QuantSide]
Xu, C., Erata, F., and J. Szefer, "Exploration of Quantum
Computer Power Side-Channels", arXiv:2304.03315v2, 9 May
2023, <https://arxiv.org/pdf/2304.03315>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini,
"Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
DOI 10.17487/RFC9528, March 2024,
<https://www.rfc-editor.org/info/rfc9528>.
[RFC9763] Becker, A., Guthrie, R., and M. Jenkins, "Related
Certificates for Use in Multiple Authentications within a
Protocol", RFC 9763, DOI 10.17487/RFC9763, June 2025,
<https://www.rfc-editor.org/info/rfc9763>.
[RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for
Post-Quantum Traditional Hybrid Schemes", RFC 9794,
DOI 10.17487/RFC9794, June 2025,
<https://www.rfc-editor.org/info/rfc9794>.
[RFC9814] Housley, R., Fluhrer, S., Kampanakis, P., and B.
Westerbaan, "Use of the SLH-DSA Signature Algorithm in the
Cryptographic Message Syntax (CMS)", RFC 9814,
DOI 10.17487/RFC9814, July 2025,
<https://www.rfc-editor.org/info/rfc9814>.
[RFC9941] Friedl, M., Mojzis, J., and S. Josefsson, "Secure Shell
(SSH) Key Exchange Method Using Hybrid Streamlined NTRU
Prime sntrup761 and X25519 with SHA-512:
sntrup761x25519-sha512", RFC 9941, DOI 10.17487/RFC9941,
April 2026, <https://www.rfc-editor.org/info/rfc9941>.
[RSA10SC] QuintessenceLabs, "Breaking RSA Encryption - an Update on
the State-of-the-Art", 13 June 2019,
<https://www.quintessencelabs.com/blog/breaking-rsa-
encryption-update-state-art>.
[RSA8HRS] Gidney, C. and M. Ekera, "How to factor 2048 bit RSA
integers in 8 hours using 20 million noisy qubits",
arXiv:1905.09749v3, 13 April 2021,
<https://arxiv.org/abs/1905.09749>.
[RSAShor] Beauregard, S., "Circuit for Shor's algorithm using 2n+3
qubits", arXiv:quant-ph/0205095v3, 21 February 2003,
<https://arxiv.org/pdf/quant-ph/0205095.pdf>.
[SaberSide]
Ngo, K., Dubrova, E., and T. Johansson, "A side-channel
attack on a masked and shuffled software implementation of
Saber", Journal of Cryptographic Engineering, vol. 13, pp.
443-460, DOI 10.1007/s13389-023-00315-3, 25 April 2023,
<https://link.springer.com/article/10.1007/
s13389-023-00315-3>.
[Serious-Crypt]
Aumasson, J., "Serious Cryptography, 2nd Edition", ISBN
9781718503847, August 2024.
[SideCh] Ngo, K., Wang, R., Dubrova, E., and N. Paulsrud, "Side-
Channel Attacks on Lattice-Based KEMs Are Not Prevented by
Higher-Order Masking", Cryptology ePrint Archive, Paper
2022/919, 2022, <https://eprint.iacr.org/2022/919>.
[SP-1800-38C]
Newhouse, W., Souppaya, M., Barke, W., Brown, C.,
Kampanakis, P., Goodman, J., Prat, J., Larrieu, R., Gray,
J., Ounsworth, M., Viana, C., Gong, H. L. V., Kwiatkowsk,
K., Hu, A., Burns, R., Paquin, C., Gilbert, J., Scinta,
G., Kim, E., and V. Krumme, "Migration to Post-Quantum
Cryptography Quantum Readiness: Testing Draft Standards,
Volume C: Quantum-Resistant Cryptography Technology
Interoperability and Performance Report", Preliminary
Draft, NIST SP 1800-38C, December 2023,
<https://www.nccoe.nist.gov/sites/default/files/2023-12/
pqc-migration-nist-sp-1800-38c-preliminary-draft.pdf>.
[SP-800-56C]
Barker, E., Chen, L., and R. Davis, "Recommendation for
Key-Derivation Methods in Key-Establishment Schemes", NIST
SP 800-56Cr2, DOI 10.6028/NIST.SP.800-56Cr2, August 2020,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Cr2.pdf>.
[Threat-Report]
Mosca, M. and M. Piani, "Quantum Threat Timeline Report
2020", Global Risk Institute, 27 January 2021,
<https://globalriskinstitute.org/publications/quantum-
threat-timeline-report-2020/>.
[TLS-HYB-KEY-EXCH]
Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key
exchange in TLS 1.3", Work in Progress, Internet-Draft,
draft-ietf-tls-hybrid-design-16, 7 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
hybrid-design-16>.
[X-WING] Connolly, D., Schwabe, P., and B. Westerbaan, "X-Wing:
general-purpose hybrid post-quantum KEM", Work in
Progress, Internet-Draft, draft-connolly-cfrg-xwing-kem-
10, 2 March 2026, <https://datatracker.ietf.org/doc/html/
draft-connolly-cfrg-xwing-kem-10>.
This document leverages text from an earlier Internet-Draft by Paul Hoffman. Thanks to Dan Wing, Florence D, Thom Wiggers, Sophia Grundner-Culemann, Panos Kampanakis, Ben S, Sofia Celi, Melchior Aelmans, Falko Strenzke, Deirdre Connolly, Hani Ezzadeen, Britta Hale, Scott Rose, Hilarie Orman, Thomas Fossati, Roman Danyliw, Mike Bishop, Mališa Vučinić, Éric Vyncke, Deb Cooley, Dirk Von Hugo, and Daniel Van Geest for the discussion, review and comments.
この文書は、Paul Hoffman による以前の Internet-Draft のテキストを活用しています。Dan Wing、Florence D、Thom Wiggers、Sophia Grundner-Culemann、Panos Kampanakis、Ben S、Sofia Celi、Melchior Aelmans、Falko Strenzke、Deirdre Connolly、Hani Ezzadeen、Britta Hale、Scott Rose、Hilary Orman、Thomas Fossati、Roman Danyliw、Mike Bishop、Mališa に感謝します。Vučinić、Éric Vyncke、Deb Cooley、Dirk Von Hugo、Daniel Van Geest にディスカッション、レビュー、コメントを提供していただきました。
In particular, the authors would like to acknowledge the contributions to this document by Kris Kwiatkowski.
特に、著者らは、この文書に対する Kris Kwiatkowski の貢献に感謝したいと思います。
Aritra Banerjee
Nokia
London
United Kingdom
Email: aritra.banerjee@nokia.com
Tirumaleswar Reddy.K
Nokia
Bangalore
Karnataka
India
Email: k.tirumaleswar_reddy@nokia.com
Dimitrios Schoinianakis
Nokia
Athens
Greece
Email: dimitrios.schoinianakis@nokia-bell-labs.com
Timothy Hollebeek
DigiCert
Pittsburgh, PA
United States of America
Email: tim.hollebeek@digicert.com
Mike Ounsworth
Entrust Limited
2500 Solandt Road, Suite 100
Ottawa, Ontario K2K 3G5
Canada
Email: mike@ounsworth.ca