Internet Engineering Task Force (IETF) D. Stebila
Request for Comments: 9954 University of Waterloo
Category: Informational S. Fluhrer
ISSN: 2070-1721 Cisco Systems
S. Gueron
U. Haifa & Meta
July 2026
Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if a way is found to defeat the encryption for all but one of the component algorithms. It is motivated by the transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3.
ハイブリッド キー交換とは、複数のキー交換アルゴリズムを同時に使用し、コンポーネント アルゴリズムの 1 つを除くすべての暗号化を破る方法が見つかった場合でも、セキュリティを提供するという目的でその結果を組み合わせることを指します。これは、ポスト量子暗号への移行が動機となっています。この文書は、トランスポート層セキュリティ (TLS) プロトコル バージョン 1.3 におけるハイブリッド キー交換の構造を提供します。
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/rfc9954.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9954 で入手できます。
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
1.1. Terminology
1.2. Motivation for Use of Hybrid Key Exchange
1.3. Scope
1.4. Goals
2. Key Encapsulation Mechanisms
3. Construction for Hybrid Key Exchange
3.1. Negotiation
3.2. Transmitting Public Keys and Ciphertexts
3.3. Shared Secret Calculation
4. Discussion
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Related Work
Acknowledgements
Authors' Addresses
This document gives a construction for hybrid key exchange in TLS 1.3. The overall design approach is a simple, "concatenation"-based approach: Each hybrid key exchange combination should be viewed as a single new key exchange method that should be negotiated and transmitted using the existing TLS 1.3 mechanisms.
この文書では、TLS 1.3 におけるハイブリッド鍵交換の構造について説明します。全体的な設計アプローチは、シンプルな「連結」ベースのアプローチです。各ハイブリッド鍵交換の組み合わせは、既存の TLS 1.3 メカニズムを使用してネゴシエートおよび送信される必要がある単一の新しい鍵交換方式として見なされます。
This document does not propose specific post-quantum mechanisms; see Section 1.3 for more on the scope of this document.
この文書は、特定のポスト量子メカニズムを提案するものではありません。この文書の範囲の詳細については、セクション 1.3 を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
For the purposes of this document, it is helpful to divide cryptographic algorithms into two classes:
このドキュメントの目的上、暗号アルゴリズムを次の 2 つのクラスに分類すると役立ちます。
* "Traditional" algorithms: Algorithms that are widely deployed today but may be deprecated in the future. In the context of TLS 1.3, examples of traditional key exchange algorithms include Elliptic Curve Diffie-Hellman (ECDH) using secp256r1 or x25519 or finite field Diffie-Hellman.
* 「従来の」アルゴリズム: 現在広く導入されているが、将来的には非推奨になる可能性があるアルゴリズム。TLS 1.3 のコンテキストでは、従来の鍵交換アルゴリズムの例には、secp256r1 または x25519 を使用する楕円曲線ディフィー ヘルマン (ECDH)、または有限体ディフィー ヘルマンが含まれます。
* "Next-generation" (or "next-gen") algorithms: Algorithms that are not yet widely deployed but may eventually be widely deployed. An additional facet of these algorithms is that the cryptographic community may have less confidence in their security due to them being relatively new or less studied. This includes "post-quantum" algorithms.
* 「次世代」 (または「次世代」) アルゴリズム: まだ広く導入されていないが、最終的には広く導入される可能性があるアルゴリズム。これらのアルゴリズムのもう 1 つの側面は、アルゴリズムが比較的新しいか、あまり研究されていないため、暗号化コミュニティがそのセキュリティに自信を持っていない可能性があることです。これには「ポスト量子」アルゴリズムが含まれます。
In this context, "hybrid" key exchange means the use of two (or more) key exchange algorithms based on different cryptographic assumptions, e.g., one traditional algorithm and one next-generation algorithm, with the purpose of the final session key being secure as long as at least one of the component key exchange algorithms remains unbroken. When one of the algorithms is traditional and one is post-quantum, this is a Post-Quantum Traditional Hybrid Scheme [PQUIP-TERM]; while this is the initial use case for this document, the document is not limited to this case. This document uses the term "component" algorithms to refer to the algorithms combined in a hybrid key exchange.
この文脈において、「ハイブリッド」鍵交換とは、コンポーネント鍵交換アルゴリズムの少なくとも 1 つが壊れていない限り、最終セッション鍵が安全であることを目的として、異なる暗号学的前提に基づいた 2 つ (またはそれ以上) の鍵交換アルゴリズム (たとえば、1 つの従来型アルゴリズムと 1 つの次世代アルゴリズム) を使用することを意味します。アルゴリズムの 1 つが従来型で、もう 1 つがポスト量子である場合、これはポスト量子従来型ハイブリッド スキーム [PQUIP-TERM] です。これはこのドキュメントの最初の使用例ですが、このドキュメントはこのケースに限定されません。この文書では、ハイブリッド鍵交換で組み合わされるアルゴリズムを指すために「コンポーネント」アルゴリズムという用語を使用します。
Some researchers prefer the term "composite" to refer to the use of multiple algorithms to distinguish from "hybrid public key encryption", in which a key encapsulation mechanism and data encapsulation mechanism are combined to create public key encryption.
研究者の中には、キーカプセル化メカニズムとデータカプセル化メカニズムを組み合わせて公開キー暗号化を作成する「ハイブリッド公開キー暗号化」と区別するために、複数のアルゴリズムの使用を指す「複合」という用語を好む人もいます。
It is intended that the component algorithms within a hybrid key exchange are to be performed, that is, negotiated and transmitted, within the TLS 1.3 handshake. Any out-of-band method of exchanging keying material is considered out-of-scope.
ハイブリッド キー交換内のコンポーネント アルゴリズムは、TLS 1.3 ハンドシェイク内で実行、つまりネゴシエートおよび送信されることが意図されています。帯域外で鍵素材を交換する方法は、対象外とみなされます。
The primary motivation of this document is preparing for post-quantum algorithms. However, it is possible that public key cryptography based on alternative mathematical constructions will be desired to mitigate risks independent of the advent of a quantum computer, for example, because of a cryptanalytic breakthrough. As such, this document opts for the more generic term "next-generation" algorithms rather than exclusively "post-quantum" algorithms.
このドキュメントの主な目的は、ポスト量子アルゴリズムの準備です。ただし、量子コンピューターの出現とは関係なく、たとえば暗号解読のブレークスルーにより、リスクを軽減するために、代替の数学的構造に基づく公開キー暗号化が望まれる可能性があります。そのため、このドキュメントでは、専ら「ポスト量子」アルゴリズムではなく、より一般的な用語「次世代」アルゴリズムを選択します。
Note that TLS 1.3 uses the term "groups" to refer to key exchange algorithms -- for example, the supported_groups extension -- since all key exchange algorithms in TLS 1.3 are Diffie-Hellman-based. As a result, some parts of this document will refer to data structures or messages with the term "group" in them despite using a key exchange algorithm that is neither Diffie-Hellman-based nor a group.
TLS 1.3 のすべての鍵交換アルゴリズムは Diffie-Hellman ベースであるため、TLS 1.3 では鍵交換アルゴリズム (supported_groups 拡張子など) を指すために「グループ」という用語が使用されることに注意してください。その結果、このドキュメントの一部の部分では、Diffie-Hellman ベースでもグループでもない鍵交換アルゴリズムを使用しているにもかかわらず、「グループ」という用語が含まれるデータ構造またはメッセージに言及します。
A hybrid key exchange algorithm allows early adopters eager for post-quantum security to have the potential of post-quantum security (possibly from a less-well-studied algorithm) while still retaining at least the security currently offered by traditional algorithms. They may even need to retain traditional algorithms due to regulatory constraints, for example, US National Institute of Standards and Technology (NIST) FIPS compliance.
ハイブリッド鍵交換アルゴリズムを使用すると、ポスト量子セキュリティに熱心な早期導入者は、少なくとも現在従来のアルゴリズムによって提供されているセキュリティを維持しながら、ポスト量子セキュリティの可能性を (おそらくあまり研究されていないアルゴリズムから) 得ることができます。米国国立標準技術研究所 (NIST) の FIPS 準拠などの規制上の制約により、従来のアルゴリズムを保持する必要がある場合もあります。
Ideally, one would not use hybrid key exchange: One would have confidence in a single algorithm and parameterization that will stand the test of time. However, this may not be the case in the face of quantum computers and cryptanalytic advances more generally.
理想的には、ハイブリッド鍵交換は使用しません。時間の試練に耐える単一のアルゴリズムとパラメーター化に自信を持つことになります。しかし、より一般的に量子コンピューターと暗号解読の進歩に直面すると、これは当てはまらない可能性があります。
Many (though not all) post-quantum algorithms currently under consideration are relatively new; they have not been subject to the same depth of study as RSA and finite field or elliptic curve Diffie-Hellman; thus, the security community does not necessarily have as much confidence in their fundamental security or the concrete security level of specific parameterizations.
現在検討されている多くの (すべてではありませんが) ポスト量子アルゴリズムは比較的新しいものです。これらは、RSA や有限体または楕円曲線の Diffie-Hellman ほど深くは研究されていません。したがって、セキュリティ コミュニティは、基本的なセキュリティや特定のパラメータ設定の具体的なセキュリティ レベルに対して、必ずしもそれほど自信を持っているわけではありません。
Moreover, it is possible that after next-generation algorithms are defined, and for a period of time thereafter, conservative users may not have full confidence in some algorithms.
さらに、次世代アルゴリズムが定義された後、その後しばらくの間は、保守的なユーザーが一部のアルゴリズムに完全な信頼を持てなくなる可能性があります。
Some users may want to accelerate adoption of post-quantum cryptography due to the threat of retroactive decryption (also known as "harvest-now-decrypt-later"): If a cryptographic assumption is broken due to the advent of a quantum computer or some other cryptanalytic breakthrough, confidentiality of information can be broken retroactively by any adversary who has passively recorded handshakes and encrypted communications. Hybrid key exchange enables potential security against retroactive decryption while not fully abandoning traditional cryptosystems.
一部のユーザーは、遡及的復号化 (「ハーベスト・ナウ・デクリプト・レイター」とも呼ばれる) の脅威のため、ポスト量子暗号の採用を加速したいと考えているかもしれません。量子コンピューターの出現やその他の暗号解読のブレークスルーによって暗号学の前提が崩れた場合、ハンドシェイクや通信の暗号化を受動的に記録した攻撃者によって、情報の機密性が遡って破られる可能性があります。ハイブリッド鍵交換により、従来の暗号システムを完全に放棄することなく、遡及的な復号に対する潜在的なセキュリティが可能になります。
As such, there may be users for whom hybrid key exchange is an appropriate step prior to an eventual transition to next-generation algorithms. Users should consider the confidence they have in each hybrid component to assess that the hybrid system meets the desired motivation.
そのため、最終的に次世代アルゴリズムに移行する前に、ハイブリッド鍵交換が適切なステップとなるユーザーもいる可能性があります。ユーザーは、ハイブリッド システムが望ましい動機を満たしているかどうかを評価するために、各ハイブリッド コンポーネントに対する自信を考慮する必要があります。
This document focuses on hybrid ephemeral key exchange in TLS 1.3 [TLS13]. It intentionally does not address:
この文書は、TLS 1.3 [TLS13] におけるハイブリッド一時鍵交換に焦点を当てています。意図的に次のことには触れていません。
* Selecting which next-generation algorithms to use in TLS 1.3 or algorithm identifiers or encoding mechanisms for next-generation algorithms.
* TLS 1.3 で使用する次世代アルゴリズム、または次世代アルゴリズムのアルゴリズム識別子またはエンコード メカニズムを選択します。
* Authentication using next-generation algorithms. While quantum computers could retroactively decrypt previous sessions, session authentication cannot be retroactively broken.
* 次世代アルゴリズムを使用した認証。量子コンピューターは以前のセッションを遡って復号化できますが、セッション認証を遡及的に破ることはできません。
The primary goal of a hybrid key exchange mechanism is to facilitate the establishment of a shared secret that remains secure as long as one of the component key exchange mechanisms remains unbroken.
ハイブリッド鍵交換メカニズムの主な目的は、コンポーネント鍵交換メカニズムの 1 つが壊れていない限り、安全な共有秘密の確立を容易にすることです。
In addition to the primary cryptographic goal, there may be several additional goals in the context of TLS 1.3:
TLS 1.3 のコンテキストでは、主要な暗号化の目標に加えて、いくつかの追加の目標が存在する場合があります。
* Backwards compatibility: Clients and servers who are "hybrid-aware", i.e., compliant with whatever hybrid key exchange standard is developed for TLS, should remain compatible with endpoints and middleboxes that are not hybrid-aware. The three scenarios to consider are:
* 下位互換性: 「ハイブリッド対応」、つまり TLS 用に開発されたハイブリッド鍵交換標準に準拠しているクライアントおよびサーバーは、ハイブリッド対応ではないエンドポイントおよびミドルボックスとの互換性を維持する必要があります。考慮すべき 3 つのシナリオは次のとおりです。
1. Hybrid-aware client, hybrid-aware server: These parties should establish a hybrid shared secret.
1. ハイブリッド対応クライアント、ハイブリッド対応サーバー: これらの当事者はハイブリッド共有秘密を確立する必要があります。
2. Hybrid-aware client, non-hybrid-aware server: These parties should establish a non-hybrid shared secret (assuming the hybrid-aware client is willing to downgrade to non-hybrid-only).
2. ハイブリッド対応クライアント、非ハイブリッド対応サーバー: これらの関係者は、非ハイブリッド共有秘密を確立する必要があります (ハイブリッド対応クライアントが非ハイブリッド専用にダウングレードする意思があると仮定します)。
3. Non-hybrid-aware client, hybrid-aware server: These parties should establish a non-hybrid shared secret (assuming the hybrid-aware server is willing to downgrade to non-hybrid-only).
3. 非ハイブリッド対応クライアント、ハイブリッド対応サーバー: これらの関係者は、非ハイブリッド共有秘密を確立する必要があります (ハイブリッド対応サーバーが非ハイブリッド専用にダウングレードする意思があると仮定します)。
Ideally, backwards compatibility should be achieved without extra round trips and without sending duplicate information; see below.
理想的には、余分なラウンドトリップや重複した情報の送信を行わずに下位互換性を実現する必要があります。以下を参照してください。
* High performance: Use of hybrid key exchange should not be prohibitively expensive in terms of computational performance. In general, this will depend on the performance characteristics of the specific cryptographic algorithms used and, as such, is outside the scope of this document. See [PST] for preliminary results about performance characteristics.
* 高いパフォーマンス: ハイブリッド鍵交換の使用は、計算パフォーマンスの点で法外に高価であってはなりません。一般に、これは使用される特定の暗号化アルゴリズムのパフォーマンス特性に依存するため、このドキュメントの範囲外です。パフォーマンス特性に関する暫定的な結果については、[PST] を参照してください。
* Low latency: Use of hybrid key exchange should not substantially increase the latency experienced to establish a connection. Factors affecting this may include the following:
* 低遅延: ハイブリッド キー交換を使用しても、接続を確立する際の遅延が大幅に増加することはありません。これに影響を与える要因には次のものが含まれる可能性があります。
- The computational performance characteristics of the specific algorithms used. See above.
- 使用される特定のアルゴリズムの計算パフォーマンス特性。上記を参照してください。
- The size of messages to be transmitted. Public key and ciphertext sizes for post-quantum algorithms range from hundreds of bytes to over one hundred kilobytes, so this impact can be substantial. See [PST] for preliminary results in a laboratory setting and [LANGLEY] for preliminary results on more realistic networks.
- 送信されるメッセージのサイズ。ポスト量子アルゴリズムの公開鍵と暗号文のサイズは、数百バイトから 100 キロバイトを超えるまでにわたるため、この影響は重大になる可能性があります。実験室環境での暫定結果については [PST] を、より現実的なネットワークでの暫定結果については [LANGLEY] を参照してください。
- Additional round trips added to the protocol. See below.
- 追加の往復がプロトコルに追加されました。以下を参照してください。
* No extra round trips: Attempting to negotiate hybrid key exchange should not lead to extra round trips in any of the three hybrid-aware/non-hybrid-aware scenarios listed above.
* 余分なラウンド トリップがない: ハイブリッド キー交換をネゴシエートしようとすると、上記の 3 つのハイブリッド対応/非ハイブリッド対応シナリオのいずれでも余分なラウンド トリップが発生してはなりません。
* Minimal duplicate information: Attempting to negotiate hybrid key exchange should not mean having to send multiple public keys of the same type.
* 重複情報を最小限に抑える: ハイブリッド鍵交換のネゴシエーションを試行する場合、同じタイプの複数の公開鍵を送信する必要があります。
The tolerance for lower performance and increased latency due to use of hybrid key exchange will depend on the context and use case of the systems and the network involved.
ハイブリッド キー交換の使用によるパフォーマンスの低下と遅延の増加に対する許容度は、関連するシステムとネットワークのコンテキストとユース ケースによって異なります。
This document models key agreement as key encapsulation mechanisms (KEMs), which consist of three algorithms:
このドキュメントでは、鍵合意を鍵カプセル化メカニズム (KEM) としてモデル化します。KEM は、次の 3 つのアルゴリズムで構成されます。
* KeyGen() -> (pk, sk): A probabilistic key generation algorithm, which generates a public key pk and a secret key sk.
* KeyGen() -> (pk, sk): 確率的鍵生成アルゴリズム。公開鍵 pk と秘密鍵 sk を生成します。
* Encaps(pk) -> (ct, ss): A probabilistic encapsulation algorithm, which takes as input a public key pk and outputs a ciphertext ct and shared secret ss.
* Encaps(pk) -> (ct, ss): 確率的カプセル化アルゴリズム。入力として公開鍵 pk を受け取り、暗号文 ct と共有秘密 ss を出力します。
* Decaps(sk, ct) -> ss: A decapsulation algorithm, which takes as input a secret key sk and ciphertext ct and outputs a shared secret ss or, in some cases, a distinguished error value.
* Decaps(sk, ct) -> ss: 秘密鍵 sk と暗号文 ct を入力として受け取り、共有秘密 ss または場合によっては識別されたエラー値を出力するカプセル化解除アルゴリズム。
The main security property for KEMs is indistinguishability under adaptive chosen ciphertext attack (IND-CCA2), which means that shared secret values should be indistinguishable from random strings even given the ability to have other arbitrary ciphertexts decapsulated. IND-CCA2 corresponds to security against an active attacker, and the public key and secret key pair can be treated as a long-term key or reused. A common design pattern for obtaining security under key reuse is to apply the Fujisaki-Okamoto (FO) transform [FO] or a variant thereof [HHK].
KEM の主なセキュリティ特性は、適応型選択暗号文攻撃 (IND-CCA2) の下での識別不可能性です。これは、他の任意の暗号文をカプセル化解除する能力があるとしても、共有秘密値はランダムな文字列と区別できないことを意味します。IND-CCA2は、積極的な攻撃者に対するセキュリティに対応しており、公開鍵と秘密鍵のペアを長期鍵として扱ったり、再利用したりすることができます。キーの再利用の下でセキュリティを確保するための一般的な設計パターンは、Fujisaki-Okamoto (FO) 変換 [FO] またはその変形 [HHK] を適用することです。
A weaker security notion is indistinguishability under chosen plaintext attack (IND-CPA), which means that the shared secret values should be indistinguishable from random strings given a copy of the public key. IND-CPA roughly corresponds to security against a passive attacker and sometimes corresponds to one-time key exchange.
セキュリティの概念が弱いのは、選択平文攻撃 (IND-CPA) の下での区別がつかないことです。これは、共有秘密の値が、公開鍵のコピーが与えられたランダムな文字列と区別できないことを意味します。IND-CPA は、受動的な攻撃者に対するセキュリティにほぼ対応し、場合によっては 1 回限りの鍵交換に対応します。
See [KATZ] or [HHK] for definitions of IND-CCA2 and IND-CPA security.
IND-CCA2 および IND-CPA セキュリティの定義については、[KATZ] または [HHK] を参照してください。
Key exchange in TLS 1.3 is phrased in terms of Diffie-Hellman key exchange in a group. DH key exchange can be modeled as a KEM, with (1) KeyGen corresponding to selecting an exponent x as the secret key and computing the public key g^x, (2) encapsulation corresponding to selecting an exponent y and computing the ciphertext g^y and the shared secret g^(xy), and (3) decapsulation corresponding to computing the shared secret g^(xy). See [HPKE] for more details of such Diffie-Hellman-based key encapsulation mechanisms. Diffie-Hellman key exchange, when viewed as a KEM, does not formally satisfy IND-CCA2 security but is still safe to use for ephemeral key exchange in TLS 1.3; see, for example, [DOWLING].
TLS 1.3 の鍵交換は、グループ内での Diffie-Hellman 鍵交換という用語で表現されます。DH 鍵交換は KEM としてモデル化できます。(1) KeyGen は秘密鍵として指数 x を選択し、公開鍵 g^x を計算することに対応し、(2) カプセル化は指数 y を選択し、暗号文 g^y と共有秘密 g^(xy) を計算することに対応し、(3) カプセル化解除は共有秘密 g^(xy) を計算することに対応します。このような Diffie-Hellman ベースの鍵カプセル化メカニズムの詳細については、[HPKE] を参照してください。Diffie-Hellman 鍵交換は、KEM として見た場合、正式には IND-CCA2 セキュリティを満たしていませんが、TLS 1.3 での一時的な鍵交換には安全に使用できます。たとえば、[ダウリング] を参照してください。
TLS 1.3 does not require that ephemeral public keys be used only in a single key exchange session; some implementations may reuse them, at the cost of limited forward secrecy. As a result, any KEM used in the manner described in this document MUST explicitly be designed to be secure in the event that the public key is reused. Finite field and elliptic curve Diffie-Hellman key exchange methods used in TLS 1.3 satisfy this criteria. For generic KEMs, this means satisfying IND-CCA2 security or having a transform like the Fujisaki-Okamoto transform [FO] [HHK] applied. While it is recommended that implementations avoid reuse of KEM public keys, implementations that do reuse KEM public keys MUST ensure that the number of reuses of a KEM public key abides by any bounds in the specification of the KEM or subsequent security analyses. Implementations MUST NOT reuse randomness in the generation of KEM ciphertexts.
TLS 1.3 では、一時的な公開鍵を単一の鍵交換セッションでのみ使用する必要はありません。一部の実装では、限定された前方機密性を犠牲にして、それらを再利用する場合があります。結果として、この文書で説明されている方法で使用される KEM は、公開鍵が再利用される場合でも安全になるように明示的に設計しなければなりません (MUST)。TLS 1.3 で使用される有限体および楕円曲線の Diffie-Hellman 鍵交換方式は、この基準を満たします。汎用 KEM の場合、これは IND-CCA2 セキュリティを満たすか、Fujisaki-Okamoto 変換 [FO] [HHK] のような変換を適用することを意味します。実装では KEM 公開鍵の再利用を避けることが推奨されますが、KEM 公開鍵を再利用する実装では、KEM 公開鍵の再利用回数が KEM の仕様またはその後のセキュリティ分析の制限に従うことを保証しなければなりません (MUST)。実装では、KEM 暗号文の生成にランダム性を再利用してはなりません。
Each particular combination of algorithms in a hybrid key exchange will be represented as a NamedGroup and sent in the supported_groups extension. No internal structure or grammar is implied or required in the value of the identifier; they are simply opaque identifiers.
ハイブリッド鍵交換におけるアルゴリズムの特定の組み合わせはそれぞれ NamedGroup として表され、supported_groups 拡張機能で送信されます。識別子の値には内部構造や文法が暗示されたり、要求されたりすることはありません。これらは単に不透明な識別子です。
Each value representing a hybrid key exchange will correspond to an ordered pair of two or more algorithms. (Note that this is independent from future documents standardizing solely post-quantum key exchange methods, which would have to be assigned their own identifier.)
ハイブリッド鍵交換を表す各値は、2 つ以上のアルゴリズムの順序付きペアに対応します。(これは、独自の識別子を割り当てる必要がある量子後鍵交換方式のみを標準化する将来の文書とは独立していることに注意してください。)
This document takes the relatively simple "concatenation approach": The messages from the two or more algorithms being hybridized will be concatenated together and transmitted as a single value to avoid having to change existing data structures. The values are directly concatenated, without any additional encoding or length fields; the representation and length of elements MUST be fixed once the algorithm is fixed.
このドキュメントでは、比較的単純な「連結アプローチ」を採用しています。つまり、ハイブリッド化されている 2 つ以上のアルゴリズムからのメッセージが連結され、単一の値として送信されるため、既存のデータ構造を変更する必要がなくなります。値は、追加のエンコードや長さフィールドを使用せずに直接連結されます。アルゴリズムが修正されたら、要素の表現と長さを修正しなければなりません (MUST)。
Recall that, in TLS 1.3 ([TLS13], Section 4.2.8), a KEM public key or KEM ciphertext is represented as a KeyShareEntry:
TLS 1.3 ([TLS13]、セクション 4.2.8) では、KEM 公開キーまたは KEM 暗号文が KeyShareEntry として表されることを思い出してください。
struct {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} KeyShareEntry;
These are transmitted in the extension_data fields of KeyShareClientHello and KeyShareServerHello extensions:
これらは、KeyShareClientHello 拡張機能と KeyShareServerHello 拡張機能の extension_data フィールドで送信されます。
struct {
KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello;
struct {
KeyShareEntry server_share;
} KeyShareServerHello;
The client's shares are listed in descending order of client preference; the server selects one algorithm and sends its corresponding share.
クライアントのシェアは、クライアントの優先順位の降順でリストされます。サーバーは 1 つのアルゴリズムを選択し、対応する共有を送信します。
For a hybrid key exchange, the key_exchange field of a KeyShareEntry is the concatenation of the key_exchange field for each of the constituent algorithms. The order of shares in the concatenation MUST be the same as the order of algorithms indicated in the definition of the NamedGroup.
ハイブリッド鍵交換の場合、KeyShareEntry の key_exchange フィールドは、構成アルゴリズムごとの key_exchange フィールドを連結したものになります。連結内の共有の順序は、NamedGroup の定義で示されたアルゴリズムの順序と同じでなければなりません。
For the client's share, the key_exchange value contains the concatenation of the pk outputs of the corresponding KEMs' KeyGen algorithms if that algorithm corresponds to a KEM or the (EC)DH ephemeral key share if that algorithm corresponds to an (EC)DH group. For the server's share, the key_exchange value contains the concatenation of the ct outputs of the corresponding KEMs' Encaps algorithms if that algorithm corresponds to a KEM or the (EC)DH ephemeral key share if that algorithm corresponds to an (EC)DH group.
クライアントの共有の場合、key_exchange 値には、対応する KEM の KeyGen アルゴリズム (そのアルゴリズムが KEM に対応する場合) の pk 出力の連結が含まれ、そのアルゴリズムが (EC)DH グループに対応する場合は (EC)DH 一時キー共有が含まれます。サーバーの共有の場合、key_exchange 値には、対応する KEM の Encaps アルゴリズムの ct 出力の連結が含まれます (そのアルゴリズムが KEM に対応する場合)、または (EC)DH 一時キー共有 (そのアルゴリズムが (EC)DH グループに対応する場合)。
Section 4.2.8 of [TLS13] requires that "The key_exchange values for each KeyShareEntry MUST be generated independently." In the context of this document, the same algorithm may appear in multiple named groups; thus, this document relaxes the above requirement to allow the same key_exchange value for the same algorithm to be reused in multiple KeyShareEntry records sent within the same ClientHello. However, key_exchange values for different algorithms MUST be generated independently. Explicitly, if the NamedGroup is the hybrid key exchange MyECDHMyPQKEM, the KeyShareEntry.key_exchange values MUST be generated in one of the following two ways:
[TLS13] のセクション 4.2.8 では、「各 KeyShareEntry の key_exchange 値は独立して生成されなければなりません (MUST)」と規定されています。このドキュメントの文脈では、同じアルゴリズムが複数の名前付きグループに現れる場合があります。したがって、この文書は上記の要件を緩和して、同じアルゴリズムの同じ key_exchange 値を、同じ ClientHello 内で送信される複数の KeyShareEntry レコードで再利用できるようにします。ただし、異なるアルゴリズムの key_exchange 値は個別に生成されなければなりません (MUST)。明示的に、NamedGroup がハイブリッド鍵交換 MyECDHMyPQKEM である場合、KeyShareEntry.key_exchange 値は次の 2 つの方法のいずれかで生成されなければなりません。
Fully independently:
完全に独立して:
MyECDHMyPQKEM.KeyGen() = (MyECDH.KeyGen(), MyPQKEM.KeyGen())
KeyShareClientHello {
KeyShareEntry {
NamedGroup: 'MyECDH',
key_exchange: MyECDH.KeyGen()
},
KeyShareEntry {
NamedGroup: 'MyPQKEM',
key_exchange: MyPQKEM.KeyGen()
},
KeyShareEntry {
NamedGroup: 'MyECDHMyPQKEM',
key_exchange: MyECDHMyPQKEM.KeyGen()
},
}
Reusing key_exchange values of the same component algorithm within the same ClientHello:
同じ ClientHello 内で同じコンポーネント アルゴリズムの key_exchange 値を再利用します。
myecdh_key_share = MyECDH.KeyGen()
mypqkem_key_share = MyPQKEM.KeyGen()
myecdh_mypqkem_key_share = (myecdh_key_share, mypqkem_key_share)
KeyShareClientHello {
KeyShareEntry {
NamedGroup: 'MyECDH',
key_exchange: myecdh_key_share
},
KeyShareEntry {
NamedGroup: 'MyPQKEM',
key_exchange: mypqkem_key_share
},
KeyShareEntry {
NamedGroup: 'MyECDHMyPQKEM',
key_exchange: myecdh_mypqkem_key_share
},
}
This document also takes a simple "concatenation approach" for the calculation of shared secrets: The two shared secrets are concatenated together and used as the shared secret in the existing TLS 1.3 key schedule. Again, this document does not add any additional structure (length fields) in the concatenation procedure; for both the traditional groups and post-quantum KEMs, the shared secret output length is fixed for a specific elliptic curve or parameter set.
この文書では、共有秘密の計算に単純な「連結アプローチ」も採用しています。2 つの共有秘密は連結され、既存の TLS 1.3 鍵スケジュールの共有秘密として使用されます。繰り返しますが、このドキュメントでは、連結手順に追加の構造 (長さフィールド) を追加しません。従来のグループとポスト量子 KEM の両方で、共有秘密の出力長は特定の楕円曲線またはパラメーター セットに対して固定されています。
In other words, if the NamedGroup is MyECDHMyPQKEM, the shared secret is calculated as:
つまり、NamedGroup が MyECDHMyPQKEM の場合、共有秘密は次のように計算されます。
concatenated_shared_secret = MyECDH.shared_secret
|| MyPQKEM.shared_secret
and inserted into the TLS 1.3 key schedule in place of the (EC)DHE shared secret, as shown in Figure 1.
図 1 に示すように、(EC)DHE 共有秘密の代わりに TLS 1.3 鍵スケジュールに挿入されます。
0
|
v
PSK -> HKDF-Extract = Early Secret
|
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
|
v
Derive-Secret(., "derived", "")
|
v
concatenated_shared_secret -> HKDF-Extract = Handshake Secret
^^^^^^^^^^^^^^^^^^^^^^^^^^ |
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
|
v
Derive-Secret(., "derived", "")
|
v
0 -> HKDF-Extract = Main Secret
|
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
+-----> Derive-Secret(...)
Figure 1: Key Schedule for Hybrid Key Exchange
図 1: ハイブリッド鍵交換の鍵スケジュール
In regard to FIPS compliance, the US National Institute of Standards and Technology (NIST) documents [NIST-SP-800-56C] and [NIST-SP-800-135] give recommendations for key derivation methods in key exchange protocols. Some hybrid combinations may combine the shared secret from a NIST-approved algorithm (e.g., ECDH using the nistp256/secp256r1 curve) with a shared secret from an unapproved algorithm (e.g., post-quantum). [NIST-SP-800-56C] lists simple concatenation as an approved method for generation of a hybrid shared secret in which one of the constituent shared secrets is from an approved method.
FIPS 準拠に関しては、米国国立標準技術研究所 (NIST) の文書 [NIST-SP-800-56C] および [NIST-SP-800-135] で、鍵交換プロトコルの鍵導出方法に関する推奨事項が示されています。一部のハイブリッドの組み合わせでは、NIST 承認アルゴリズム (nistp256/secp256r1 曲線を使用する ECDH など) の共有秘密と未承認アルゴリズム (ポスト量子など) の共有秘密を組み合わせる場合があります。[NIST-SP-800-56C] は、構成共有秘密の 1 つが承認された方法によるものであるハイブリッド共有秘密を生成するための承認された方法として単純連結をリストしています。
Larger public keys and/or ciphertexts:
より大きな公開鍵および/または暗号文:
The key_exchange field in the KeyShareEntry struct in Section 3.2 limits public keys and ciphertexts to 2^16-1 bytes. Some post-quantum KEMs have larger public keys and/or ciphertexts; for example, Classic McEliece's smallest parameter set has a public key size of 261,120 bytes [Classic-McEliece]. However, all defined parameter sets for the Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) [NIST-FIPS-203] have public keys and ciphertexts that fall within the TLS constraints (although this may result in ClientHello messages larger than a single packet).
セクション 3.2 の KeyShareEntry 構造体の key_exchange フィールドは、公開鍵と暗号文を 2^16-1 バイトに制限します。一部のポスト量子 KEM には、より大きな公開鍵や暗号文が含まれています。たとえば、Classic McEliece の最小パラメータ セットの公開キー サイズは 261,120 バイトです [Classic-McEliece]。ただし、モジュール格子ベースの鍵カプセル化メカニズム (ML-KEM) [NIST-FIPS-203] に定義されているすべてのパラメーター セットには、TLS 制約内に収まる公開鍵と暗号文があります (ただし、これにより、ClientHello メッセージが 1 つのパケットより大きくなる可能性があります)。
Duplication of key shares:
鍵共有の重複:
Concatenation of public keys in the key_exchange field in the KeyShareEntry struct as described in Section 3.2 can result in sending duplicate key shares. For example, if a client wants to offer support for two combinations, say "SecP256r1MLKEM768" and "X25519MLKEM768" [ECDHE-MLKEM], it would end up sending two ML-KEM-768 public keys, since the KeyShareEntry for each combination contains its own copy of an ML-KEM-768 key. This duplication may be more problematic for post-quantum algorithms that have larger public keys. On the other hand, if the client wants to offer, for example, "SecP256r1MLKEM768" and "secp256r1" (for backwards compatibility), there is relatively little duplicated data (as the secp256r1 keys are comparatively small).
セクション 3.2 で説明されているように、KeyShareEntry 構造体の key_exchange フィールドで公開鍵を連結すると、重複した鍵共有が送信される可能性があります。たとえば、クライアントが 2 つの組み合わせ、たとえば「SecP256r1MLKEM768」と「X25519MLKEM768」[ECDHE-MLKEM] のサポートを提供したい場合、各組み合わせの KeyShareEntry には ML-KEM-768 鍵の独自のコピーが含まれるため、最終的に 2 つの ML-KEM-768 公開鍵を送信することになります。この重複は、より大きな公開鍵を持つポスト量子アルゴリズムではさらに問題となる可能性があります。一方、クライアントが、たとえば「SecP256r1MLKEM768」と「secp256r1」（下位互換性のため）を提供したい場合、（secp256r1 キーが比較的小さいため）重複するデータは比較的少なくなります。
IANA has added this document as a reference for the "TLS Supported Groups" registry [IANA-TLS].
IANA は、この文書を「TLS Supported Groups」レジストリ [IANA-TLS] の参照として追加しました。
For hybrid combinations defined per this document, IANA will assign identifiers in a range that is distinct from the Finite Field Groups range. In addition, the "Recommended" column SHOULD be "N", and the "DTLS-OK" column SHOULD be "Y".
この文書に従って定義されたハイブリッドの組み合わせの場合、IANA は有限体グループの範囲とは異なる範囲で識別子を割り当てます。さらに、「推奨」列は「N」である必要があり、「DTLS-OK」列は「Y」である必要があります。
The shared secrets computed in the hybrid key exchange should be computed in a way that achieves the "hybrid" property: The resulting secret is secure as long as at least one of the component key exchange algorithms is unbroken. See [GIACON] and [BINDEL] for an investigation of these issues. Under the assumption that shared secrets are fixed length once the combination is fixed, the construction in Section 3.3 corresponds to the dual-PRF combiner of [BINDEL], which is shown to preserve security under the assumption that the hash function is a dual-PRF.
ハイブリッド鍵交換で計算される共有秘密は、「ハイブリッド」特性を達成する方法で計算される必要があります。つまり、コンポーネント鍵交換アルゴリズムの少なくとも 1 つが壊れていない限り、結果として得られる秘密は安全です。これらの問題の調査については、[GIACON] および [BINDEL] を参照してください。組み合わせが固定されると共有秘密は固定長になるという仮定の下で、セクション 3.3 の構造は [BINDEL] のデュアル PRF 結合器に対応し、ハッシュ関数がデュアル PRF であるという仮定の下でセキュリティを維持することが示されています。
As noted in Section 2, KEMs used in the manner described in this document MUST explicitly be designed to be secure in the event that the public key is reused, such as achieving IND-CCA2 security or having a transform like the Fujisaki-Okamoto transform applied. ML-KEM has such security properties. However, some other post-quantum KEMs designed to be IND-CPA-secure (i.e., without countermeasures such as the FO transform) are completely insecure under public key reuse; for example, some lattice-based IND-CPA-secure KEMs are vulnerable to attacks that recover the private key after just a few thousand samples [FLUHRER].
セクション 2 で述べたように、この文書で説明されている方法で使用される KEM は、IND-CCA2 セキュリティを達成するか、藤崎-岡本変換のような変換を適用するなど、公開鍵が再利用される場合に安全になるように明示的に設計しなければなりません (MUST)。ML-KEM にはこのようなセキュリティ特性があります。ただし、IND-CPA で安全になるように設計された (つまり、FO 変換などの対策がない) 他の一部のポスト量子 KEM は、公開鍵の再利用の下では完全に安全ではありません。たとえば、一部の格子ベースの IND-CPA セキュア KEM は、わずか数千サンプル後に秘密鍵を回復する攻撃に対して脆弱です [FLUHRER]。
*Public keys, ciphertexts, and secrets should be constant length.* This document assumes that the length of each public key, ciphertext, and shared secret is fixed once the algorithm is fixed. This is the case for ML-KEM.
*公開鍵、暗号文、および秘密は一定の長さである必要があります。* この文書では、アルゴリズムが固定されると、各公開鍵、暗号文、および共有秘密の長さが固定されることを前提としています。これは ML-KEM の場合に当てはまります。
Note that variable-length secrets are, generally speaking, dangerous. In particular, when using key material of variable length and processing it using hash functions, a timing side channel may arise. In broad terms, when the secret is longer, the hash function may need to process more blocks internally. In some unfortunate circumstances, this has led to timing attacks, e.g., the Lucky Thirteen [LUCKY13] and Raccoon [RACCOON] attacks.
一般に、可変長のシークレットは危険であることに注意してください。特に、可変長の鍵素材を使用し、それをハッシュ関数を使用して処理する場合、タイミング サイド チャネルが発生する可能性があります。大まかに言うと、シークレットが長い場合、ハッシュ関数は内部でより多くのブロックを処理する必要がある可能性があります。残念な状況では、これにより、ラッキー サーティーン [LUCKY13] 攻撃やラクーン [RACCOON] 攻撃などのタイミング攻撃が発生することがあります。
Furthermore, [AVIRAM] identifies a risk of using variable-length secrets when the hash function used in the key derivation function is no longer collision-resistant.
さらに、[AVIRAM] は、鍵導出関数で使用されるハッシュ関数が衝突耐性を持たなくなった場合に、可変長の秘密を使用するリスクを特定しています。
If concatenation were to be used with values that are not fixed-length, a length prefix or other unambiguous encoding would need to be used to ensure that the composition of the two values is injective and requires a mechanism different from that specified in this document.
固定長ではない値で連結を使用する場合は、2 つの値の合成が単射的であることを保証するために長さプレフィックスまたはその他の明確なエンコーディングを使用する必要があり、このドキュメントで指定されているものとは異なるメカニズムが必要になります。
Therefore, this specification MUST only be used with algorithms that have fixed-length shared secrets (after the variant has been fixed by the algorithm identifier in the NamedGroup negotiation in Section 3.1).
したがって、この仕様は、固定長の共有秘密を持つアルゴリズムでのみ使用しなければなりません (セクション 3.1 の NamedGroup ネゴシエーションでアルゴリズム識別子によってバリアントが修正された後)。
[FO] Fujisaki, E. and T. Okamoto, "Secure Integration of
Asymmetric and Symmetric Encryption Schemes", Journal of
Cryptology, vol. 26, no. 1, pp. 80-101,
DOI 10.1007/s00145-011-9114-1, December 2011,
<https://doi.org/10.1007/s00145-011-9114-1>.
[HHK] Hofheinz, D., Hövelmanns, K., and E. Kiltz, "A Modular
Analysis of the Fujisaki-Okamoto Transformation", Theory
of Cryptography (TCC 2017), Lecture Notes in Computer
Science, vol. 10677, pp. 341-371,
DOI 10.1007/978-3-319-70500-2_12, 2017,
<https://doi.org/10.1007/978-3-319-70500-2_12>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/info/rfc9846>.
[AVIRAM] Nimrod Aviram, Benjamin Dowling, Ilan Komargodski, Kenny
Paterson, Eyal Ronen, and Eylon Yogev, "[TLS] Combining
Secrets in Hybrid Key Exchange in TLS 1.3", 1 September
2021, <https://mailarchive.ietf.org/arch/msg/tls/
F4SVeL2xbGPaPB2GW_GkBbD_a5M/>.
[BCNS15] Bos, J., Costello, C., Naehrig, M., and D. Stebila, "Post-
Quantum Key Exchange for the TLS Protocol from the Ring
Learning with Errors Problem", 2015 IEEE Symposium on
Security and Privacy, pp. 553-570, DOI 10.1109/sp.2015.40,
May 2015, <https://doi.org/10.1109/sp.2015.40>.
[BERNSTEIN]
Bernstein, D. J., Ed., Buchmann, J., Ed., and E. Dahmen,
Ed., "Post-Quantum Cryptography", Springer Berlin,
DOI 10.1007/978-3-540-88702-7, 2009,
<https://doi.org/10.1007/978-3-540-88702-7>.
[BINDEL] Bindel, N., Brendel, J., Fischlin, M., Goncalves, B., and
D. Stebila, "Hybrid Key Encapsulation Mechanisms and
Authenticated Key Exchange", Post-Quantum Cryptography
(PQCrypto 2019), Lecture Notes in Computer Science, vol.
11505, pp. 206-226, DOI 10.1007/978-3-030-25510-7_12,
2019, <https://doi.org/10.1007/978-3-030-25510-7_12>.
[CAMPAGNA] Campagna, M. and E. Crockett, "Hybrid Post-Quantum Key
Encapsulation Methods (PQ KEM) for Transport Layer
Security 1.2 (TLS)", Work in Progress, Internet-Draft,
draft-campagna-tls-bike-sike-hybrid-07, 2 September 2021,
<https://datatracker.ietf.org/doc/html/draft-campagna-tls-
bike-sike-hybrid-07>.
[CECPQ1] Braithwaite, M., "Experimenting with Post-Quantum
Cryptography", Google Security Blog, 7 July 2016,
<https://security.googleblog.com/2016/07/experimenting-
with-post-quantum.html>.
[CECPQ2] Langley, A., "CECPQ2", 12 December 2018,
<https://www.imperialviolet.org/2018/12/12/cecpq2.html>.
[Classic-McEliece]
Josefsson, S., "Classic McEliece", Work in Progress,
Internet-Draft, draft-josefsson-mceliece-05, 23 June 2026,
<https://datatracker.ietf.org/doc/html/draft-josefsson-
mceliece-05>.
[DODIS] Dodis, Y. and J. Katz, "Chosen-Ciphertext Security of
Multiple Encryption", Theory of Cryptography (TCC 2005),
Lecture Notes in Computer Science, vol. 3378, pp. 188-209,
DOI 10.1007/978-3-540-30576-7_11, 2005,
<https://doi.org/10.1007/978-3-540-30576-7_11>.
[DOWLING] Dowling, B., Fischlin, M., Günther, F., and D. Stebila, "A
Cryptographic Analysis of the TLS 1.3 Handshake Protocol",
Journal of Cryptology, vol. 34, article 37,
DOI 10.1007/s00145-021-09384-1, July 2021,
<https://doi.org/10.1007/s00145-021-09384-1>.
[ECDHE-MLKEM]
Kwiatkowski, K., Kampanakis, P., Westerbaan, B., and D.
Stebila, "Post-quantum hybrid ECDHE-MLKEM Key Agreement
for TLSv1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-ecdhe-mlkem-05, 26 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
ecdhe-mlkem-05>.
[ETSI] Campagna, M., Ed., et al., "Quantum Safe Cryptography and
Security: An introduction, benefits, enablers and
challenges", ETSI White Paper No. 8, June 2015,
<https://www.etsi.org/images/files/ETSIWhitePapers/
QuantumSafeWhitepaper.pdf>.
[EVEN] Even, S. and O. Goldreich, "On the Power of Cascade
Ciphers", Advances in Cryptology, pp. 43-50,
DOI 10.1007/978-1-4684-4730-9_4, 1984,
<https://doi.org/10.1007/978-1-4684-4730-9_4>.
[EXTERN-PSK]
Housley, R., "TLS 1.3 Extension for Certificate-Based
Authentication with an External Pre-Shared Key", RFC 8773,
DOI 10.17487/RFC8773, March 2020,
<https://www.rfc-editor.org/info/rfc8773>.
[FLUHRER] Fluhrer, S., "Cryptanalysis of ring-LWE based key exchange
with key share reuse", Cryptology ePrint Archive, Paper
2016/085, 2016, <https://eprint.iacr.org/2016/085>.
[FRODO] Bos, J., Costello, C., Ducas, L., Mironov, I., Naehrig,
M., Nikolaenko, V., Raghunathan, A., and D. Stebila,
"Frodo: Take off the Ring! Practical, Quantum-Secure Key
Exchange from LWE", Proceedings of the 2016 ACM SIGSAC
Conference on Computer and Communications Security, pp.
1006-1018, DOI 10.1145/2976749.2978425, October 2016,
<https://doi.org/10.1145/2976749.2978425>.
[GIACON] Giacon, F., Heuer, F., and B. Poettering, "KEM Combiners",
Public-Key Cryptography (PKC 2018), Lecture Notes in
Computer Science, vol. 10769, pp. 190-218,
DOI 10.1007/978-3-319-76578-5_7, 2018,
<https://doi.org/10.1007/978-3-319-76578-5_7>.
[HARNIK] Harnik, D., Kilian, J., Naor, M., Reingold, O., and A.
Rosen, "On Robust Combiners for Oblivious Transfer and
Other Primitives", Advances in Cryptology (EUROCRYPT
2005), Lecture Notes in Computer Science, vol. 3494, pp.
96-113, DOI 10.1007/11426639_6, 2005,
<https://doi.org/10.1007/11426639_6>.
[HPKE] 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>.
[IANA-TLS] IANA, "TLS Supported Groups",
<https://www.iana.org/assignments/tls-parameters>.
[IKE-PSK] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov,
"Mixing Preshared Keys in the Internet Key Exchange
Protocol Version 2 (IKEv2) for Post-quantum Security",
RFC 8784, DOI 10.17487/RFC8784, June 2020,
<https://www.rfc-editor.org/info/rfc8784>.
[KATZ] Katz, J. and Y. Lindell, "Introduction to Modern
Cryptography", Third Edition, CRC Press, 2021.
[KIEFER] Kiefer, F. and K. Kwiatkowski, "Hybrid ECDHE-SIDH Key
Exchange for TLS", Work in Progress, Internet-Draft,
draft-kiefer-tls-ecdhe-sidh-00, 5 November 2018,
<https://datatracker.ietf.org/doc/html/draft-kiefer-tls-
ecdhe-sidh-00>.
[LANGLEY] Langley, A., "Post-quantum confidentiality for TLS", 11
April 2018, <https://www.imperialviolet.org/2018/04/11/
pqconftls.html>.
[LUCKY13] Al Fardan, N. and K. Paterson, "Lucky Thirteen: Breaking
the TLS and DTLS Record Protocols", 2013 IEEE Symposium on
Security and Privacy, pp. 526-540, DOI 10.1109/sp.2013.42,
May 2013, <https://doi.org/10.1109/sp.2013.42>.
[NIELSEN] Nielsen, M. A. and I. L. Chuang, "Quantum Computation and
Quantum Information", Cambridge University Press, 2000.
[NIST] NIST, "Post-Quantum Cryptography",
<https://www.nist.gov/pqcrypto>.
[NIST-FIPS-203]
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>.
[NIST-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://doi.org/10.6028/nist.sp.800-56cr2>.
[NIST-SP-800-135]
Dang, Q., "Recommendation for Existing Application-
Specific Key Derivation Functions", NIST SP 800-135r1,
DOI 10.6028/nist.sp.800-135r1, December 2011,
<https://doi.org/10.6028/nist.sp.800-135r1>.
[OQS-102] "OQS-OpenSSL-1-0-2_stable", commit 537b2f9, 31 January
2020, <https://github.com/open-quantum-safe/openssl/tree/
OQS-OpenSSL_1_0_2-stable>.
[OQS-111] "OQS-OpenSSL-1-1-1_stable", commit 5f49b7a, 8 January
2025, <https://github.com/open-quantum-safe/openssl/tree/
OQS-OpenSSL_1_1_1-stable>.
[OQS-PROV] "OQS Provider for OpenSSL 3", commit 573fb25, 8 January
2026,
<https://github.com/open-quantum-safe/oqs-provider/>.
[PQUIP-TERM]
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>.
[PST] Paquin, C., Stebila, D., and G. Tamvada, "Benchmarking
Post-quantum Cryptography in TLS", Post-Quantum
Cryptography (PQCrypto 2020), Lecture Notes in Computer
Science, vol. 12100, pp. 72-91,
DOI 10.1007/978-3-030-44223-1_5, 2020,
<https://doi.org/10.1007/978-3-030-44223-1_5>.
[RACCOON] Merget, R., Brinkmann, M., Aviram, N., Somorovsky, J.,
Mittmann, J., and J. Schwenk, "Raccoon Attack: Finding and
Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)",
September 2020, <https://raccoon-attack.com/>.
[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>.
[S2N] Hopkins, A. and M. Campagna, "Post-quantum TLS now
supported in AWS KMS", AWS Security Blog, 4 November 2019,
<https://aws.amazon.com/blogs/security/post-quantum-tls-
now-supported-in-aws-kms/>.
[SCHANCK] Schanck, J. M. and D. Stebila, "A Transport Layer Security
(TLS) Extension For Establishing An Additional Shared
Secret", Work in Progress, Internet-Draft, draft-schanck-
tls-additional-keyshare-00, 17 April 2017,
<https://datatracker.ietf.org/doc/html/draft-schanck-tls-
additional-keyshare-00>.
[WHYTE12] Schanck, J. M., Whyte, W., and Z. Zhang, "Quantum-Safe
Hybrid (QSH) Ciphersuite for Transport Layer Security
(TLS) version 1.2", Work in Progress, Internet-Draft,
draft-whyte-qsh-tls12-02, 22 July 2016,
<https://datatracker.ietf.org/doc/html/draft-whyte-qsh-
tls12-02>.
[WHYTE13] Whyte, W., Zhang, Z., Fluhrer, S., and O. Garcia-Morchon,
"Quantum-Safe Hybrid (QSH) Key Exchange for Transport
Layer Security (TLS) version 1.3", Work in Progress,
Internet-Draft, draft-whyte-qsh-tls13-06, 3 October 2017,
<https://datatracker.ietf.org/doc/html/draft-whyte-qsh-
tls13-06>.
[XMSS] 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>.
[ZHANG] Zhang, R., Hanaoka, G., Shikata, J., and H. Imai, "On the
Security of Multiple Encryption or CCA-security+CCA-
security=CCA-security?", Public Key Cryptography (PKC
2004), Lecture Notes in Computer Science, vol. 2947, pp.
360-374, DOI 10.1007/978-3-540-24632-9_26, 2004,
<https://doi.org/10.1007/978-3-540-24632-9_26>.
Quantum computing and post-quantum cryptography in general are outside the scope of this document. For a general introduction to quantum computing, see a standard textbook such as [NIELSEN]. For an overview of post-quantum cryptography as of 2009, see [BERNSTEIN]; while not containing more recent advances, it still provides a helpful introduction. For the current status of the NIST Post-Quantum Cryptography Standardization Project, see [NIST]. For additional perspectives on the general transition from traditional to post-quantum cryptography, see for example [ETSI], among others.
一般に量子コンピューティングとポスト量子暗号は、このドキュメントの範囲外です。量子コンピューティングの一般的な概要については、[NIELSEN] などの標準的な教科書を参照してください。2009 年時点のポスト量子暗号の概要については、[BERNSTEIN] を参照してください。最近の進歩は含まれていませんが、それでも役立つ入門書となります。NIST ポスト量子暗号標準化プロジェクトの現在の状況については、[NIST] を参照してください。従来の暗号からポスト量子暗号への一般的な移行に関する追加の観点については、たとえば [ETSI] などを参照してください。
There have been several Internet-Drafts describing mechanisms for embedding post-quantum and/or hybrid key exchange in TLS:
TLS にポスト量子鍵交換やハイブリッド鍵交換を埋め込むためのメカニズムを記述したインターネット ドラフトがいくつかあります。
* TLS 1.2: [WHYTE12], [CAMPAGNA]
* TLS 1.2: [WHYTE12]、[カンパーニャ]
* TLS 1.3: [KIEFER], [SCHANCK], [WHYTE13]
* TLS 1.3: [キーファー]、[シャンク]、[ホワイト 13]
There have been several prototype implementations for post-quantum and/or hybrid key exchange in TLS:
TLS でのポスト量子鍵交換やハイブリッド鍵交換のプロトタイプ実装はいくつかあります。
* TLS 1.2: [BCNS15], [CECPQ1], [FRODO], [OQS-102], [S2N]
* TLS 1.2: [BCNS15]、[CECPQ1]、[FRODO]、[OQS-102]、[S2N]
* TLS 1.3: [CECPQ2], [OQS-111], [OQS-PROV], [PST]
* TLS 1.3: [CECPQ2]、[OQS-111]、[OQS-PROV]、[PST]
These experimental implementations have taken an ad hoc approach and not attempted to implement one of the Internet-Drafts listed above.
これらの実験的な実装はアドホックなアプローチを採用しており、上記のインターネット ドラフトのいずれかを実装することは試みられていません。
Unrelated to post-quantum but still related to the issue of combining multiple types of keying material in TLS is the use of pre-shared keys, especially the recent TLS Working Group document on including an external pre-shared key [EXTERN-PSK].
ポスト量子とは関係ありませんが、TLS で複数のタイプの鍵マテリアルを組み合わせる問題に依然として関連しているのは、事前共有鍵の使用です。特に、外部事前共有鍵 [EXTERN-PSK] を含めることに関する最近の TLS ワーキング グループの文書です。
[RFC9370] on the multiple key exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) has been published as a Proposed Standard, and other IETF work includes post-quantum preshared keys in IKEv2 [IKE-PSK]. The eXtended Merkle Signature Scheme (XMSS) hash-based signature scheme has been published as an Informational RFC by the IRTF [XMSS].
インターネット鍵交換プロトコル バージョン 2 (IKEv2) の複数の鍵交換に関する [RFC9370] が標準案として公開されており、他の IETF の作業には IKEv2 [IKE-PSK] のポスト量子事前共有鍵が含まれています。eXtended Merkle Signature Scheme (XMSS) ハッシュベースの署名スキームは、IRTF [XMSS] によって情報 RFC として公開されました。
In the academic literature, [EVEN] initiated the study of combining multiple symmetric encryption schemes; [ZHANG], [DODIS], and [HARNIK] examined combining multiple public key encryption schemes; and [HARNIK] coined the term "robust combiner" to refer to a compiler that constructs a hybrid scheme from individual schemes while preserving security properties. [GIACON] and [BINDEL] examined combining multiple key encapsulation mechanisms.
学術文献では、[EVEN] が複数の対称暗号化方式を組み合わせる研究を開始しました。[ZHANG]、[DODIS]、および [HARNIK] は、複数の公開鍵暗号化スキームの組み合わせを検討しました。[HARNIK] は、セキュリティ特性を維持しながら個々のスキームからハイブリッド スキームを構築するコンパイラーを指す「ロバスト コンバイナー」という用語を作りました。[GIACON] と [BINDEL] は、複数の鍵カプセル化メカニズムの組み合わせを検討しました。
The ideas in this document have grown from discussions with many colleagues, including Christopher Wood, Matt Campagna, Eric Crockett, Deirdre Connolly, authors of the various hybrid documents and implementations cited in this document, and members of the TLS Working Group. The immediate impetus for this document came from discussions with attendees at the Workshop on Post-Quantum Software in Mountain View, California in January 2019. Daniel J. Bernstein and Tanja Lange commented on the risks of reuse of ephemeral public keys. Matt Campagna and the team at Amazon Web Services provided additional suggestions. Nimrod Aviram proposed restricting to fixed-length secrets.
この文書のアイデアは、Christopher Wood、Matt Campagna、Eric Crockett、Deirdre Connolly、この文書で引用されているさまざまなハイブリッド文書と実装の著者、および TLS ワーキング グループのメンバーを含む多くの同僚との議論から発展しました。この文書の直接のきっかけは、2019 年 1 月にカリフォルニア州マウンテンビューで開催されたポスト量子ソフトウェアに関するワークショップでの参加者との議論から来ました。ダニエル J. バーンスタインとタンジャ ランゲは、一時的な公開鍵の再利用のリスクについてコメントしました。Matt Campagna とアマゾン ウェブ サービスのチームは追加の提案を提供しました。Nimrod Aviram は、固定長の秘密に制限することを提案しました。
Douglas Stebila
University of Waterloo
Email: dstebila@uwaterloo.ca
Scott Fluhrer
Cisco Systems
Email: sfluhrer@cisco.com
Shay Gueron
University of Haifa and Meta
Email: shay.gueron@gmail.com