Internet Engineering Task Force (IETF) P. Kampanakis
Request for Comments: 10042 AWS
Category: Informational D. Stebila
ISSN: 2070-1721 University of Waterloo
T. Hansen
AWS
August 2026
This document defines Post-Quantum Traditional (PQ/T) Hybrid key exchange methods based on the quantum-resistant Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) standard and traditional Elliptic-Curve Diffie-Hellman (ECDH) key exchange schemes. These methods are defined for use in the Secure Shell (SSH) transport layer protocol.
この文書は、耐量子性モジュール格子ベースの鍵カプセル化メカニズム (ML-KEM) 標準および従来の楕円曲線ディフィー ヘルマン (ECDH) 鍵交換スキームに基づいたポスト量子伝統的 (PQ/T) ハイブリッド鍵交換方式を定義します。これらのメソッドは、セキュア シェル (SSH) トランスポート層プロトコルで使用するために定義されています。
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 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) の成果物です。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/rfc10042.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10042 で入手できます。
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. Requirements Language
2. PQ/T Hybrid Key Exchange
2.1. PQ/T Hybrid Key Exchange Method Abstraction
2.2. PQ/T Hybrid Key Exchange Message Numbers
2.3. PQ/T Hybrid Key Exchange Method Names
2.3.1. mlkem768nistp256-sha256
2.3.2. mlkem1024nistp384-sha384
2.3.3. mlkem768x25519-sha256
2.4. Shared Secret K
2.5. Key Derivation
3. Message Size
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. Other Combiners
Appendix B. FIPS
Acknowledgements
Authors' Addresses
Secure Shell (SSH) [RFC4251] performs key establishment using key exchange methods based on Elliptic Curve Diffie-Hellman (ECDH) style schemes defined in [RFC5656] and [RFC8731]. The cryptographic security of these key exchanges relies on certain instances of the discrete logarithm problem being computationally infeasible to solve for adversaries.
Secure Shell (SSH) [RFC4251] は、[RFC5656] および [RFC8731] で定義されている楕円曲線ディフィーヘルマン (ECDH) スタイルのスキームに基づく鍵交換方法を使用して鍵の確立を実行します。これらの鍵交換の暗号化セキュリティは、敵対者にとって計算的に解決できない離散対数問題の特定のインスタンスに依存しています。
However, if sufficiently large quantum computers become available, these instances would no longer be computationally infeasible, rendering the current key exchange and authentication methods in SSH insecure. While large quantum computers are not available today, an adversary could record the encrypted communication sent between the client and server in an SSH session and later decrypt it when sufficiently large quantum computers become available. This kind of attack is known as a 'harvest now, decrypt later' attack [RFC9958].
ただし、十分な大きさの量子コンピューターが利用可能になれば、これらのインスタンスは計算上実行不可能ではなくなり、SSH での現在の鍵交換および認証方法が安全ではなくなります。現在、大型の量子コンピューターは利用できませんが、攻撃者は SSH セッションでクライアントとサーバー間で送信された暗号化通信を記録し、後で十分な規模の量子コンピューターが利用可能になったときにそれを復号化する可能性があります。この種の攻撃は、「今すぐ収穫し、後で復号化する」攻撃として知られています [RFC9958]。
This document addresses the problem by extending the SSH transport layer protocol key exchange (Section 7 of [RFC4253]) with Post-Quantum Traditional (PQ/T) Hybrid key exchange methods [RFC9794]. It follows the migration considerations laid out in Section 4.3 of [OAM-CONS]. The security provided by each key exchange scheme in a PQ/T Hybrid key exchange method is independent. This means that the PQ/T Hybrid key exchange method will always be at least as secure as the most secure key exchange scheme executed as part of the exchange. [PQ-PROOF] and [PQ-PROOF2] contain proofs of security for such PQ/T Hybrid key exchange schemes.
この文書は、SSH トランスポート層プロトコル鍵交換 ([RFC4253] のセクション 7) を Post-Quantum Traditional (PQ/T) ハイブリッド鍵交換方式 [RFC9794] で拡張することで問題に対処します。これは、[OAM-CONS] のセクション 4.3 に示されている移行に関する考慮事項に従います。PQ/T ハイブリッド鍵交換方式の各鍵交換スキームによって提供されるセキュリティは独立しています。これは、PQ/T ハイブリッド鍵交換方式が常に、交換の一部として実行される最も安全な鍵交換スキームと少なくとも同じくらい安全であることを意味します。[PQ-PROOF] および [PQ-PROOF2] には、このような PQ/T ハイブリッド鍵交換スキームのセキュリティの証明が含まれています。
In the context of the [NIST_PQ], key exchange algorithms are formulated as Key-Encapsulation Mechanisms (KEMs), which consist of three algorithms:
[NIST_PQ] のコンテキストでは、鍵交換アルゴリズムは鍵カプセル化メカニズム (KEM) として定式化され、次の 3 つのアルゴリズムで構成されます。
'KeyGen() -> (pk, sk)':
'KeyGen() -> (pk, sk)':
A probabilistic key generation algorithm, which generates a public key 'pk' and a secret key 'sk'.
確率的鍵生成アルゴリズム。公開鍵「pk」と秘密鍵「sk」を生成します。
'Encaps(pk) -> (ct, ss)':
'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'.
確率的カプセル化アルゴリズム。公開キー「pk」を入力として受け取り、暗号文「ct」と共有秘密「ss」を出力します。
'Decaps(sk, ct) -> ss':
'デカプス(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.
秘密鍵「sk」と暗号文「ct」を入力として受け取り、共有秘密「ss」、または場合によっては識別エラー値を出力するカプセル化解除アルゴリズム。
The main security property for KEMs is indistinguishability under adaptive chosen ciphertext attacks (IND-CCA2), which means that shared secret values should be indistinguishable from random strings even given the ability to have arbitrary ciphertexts decapsulated. IND-CCA2 corresponds to security against an active attacker, and the public key / secret key pair can be treated as a long-term key or reused. 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.
KEM の主なセキュリティ特性は、適応型選択暗号文攻撃 (IND-CCA2) の下での識別不可能性です。これは、たとえ任意の暗号文をカプセル化解除する能力があったとしても、共有秘密の値はランダムな文字列と区別できないことを意味します。IND-CCA2は積極的な攻撃者に対するセキュリティに対応しており、公開鍵/秘密鍵ペアを長期鍵として扱ったり、再利用したりすることが可能です。セキュリティの概念が弱いのは、選択平文攻撃 (IND-CPA) の下での区別がつかないことです。これは、共有秘密の値が、公開鍵のコピーが与えられたランダムな文字列と区別できないことを意味します。IND-CPA は、受動的な攻撃者に対するセキュリティに大まかに対応し、場合によっては 1 回限りの鍵交換に対応します。
The post-quantum KEM used in this document is the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). ML-KEM was standardized in 2024 [FIPS203] with three parameter variants, ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This specification's PQ/T Hybrid key exchange message abstraction, key derivation, and input to the SSH hash calculation, H, align with the ones defined in [RFC9941], which uses a different quantum-resistant KEM.
このドキュメントで使用されるポスト量子 KEM は、モジュール格子ベースのキーカプセル化メカニズム (ML-KEM) です。ML-KEM は 2024 年に標準化され、ML-KEM-512、ML-KEM-768、および ML-KEM-1024 の 3 つのパラメーター バリアントで [FIPS203] されました。この仕様の PQ/T ハイブリッド鍵交換メッセージの抽象化、鍵導出、SSH ハッシュ計算への入力 H は、別の耐量子性 KEM を使用する [RFC9941] で定義されているものと一致しています。
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] で説明されているように解釈されます。
This section defines the abstract structure of a PQ/T Hybrid key exchange method. This structure must be instantiated with two key exchange schemes. The byte and string types are to be interpreted in this document as described in [RFC4251].
このセクションでは、PQ/T ハイブリッド鍵交換メソッドの抽象構造を定義します。この構造は 2 つの鍵交換スキームを使用してインスタンス化する必要があります。この文書では、バイト型と文字列型は [RFC4251] で説明されているように解釈されます。
In a PQ/T Hybrid key exchange, instead of SSH_MSG_KEXDH_INIT [RFC4253] or SSH_MSG_KEX_ECDH_INIT [RFC5656], the client sends:
PQ/T ハイブリッド鍵交換では、SSH_MSG_KEXDH_INIT [RFC4253] または SSH_MSG_KEX_ECDH_INIT [RFC5656] の代わりに、クライアントは以下を送信します。
byte SSH_MSG_KEX_HYBRID_INIT
string C_INIT
where C_INIT is the concatenation of C_PK2 and C_PK1 (C_INIT = C_PK2 || C_PK1, where || depicts concatenation). C_PK1 and C_PK2 represent the ephemeral client public keys used for each key exchange of the PQ/T Hybrid mechanism. Typically, C_PK1 represents a traditional / classical (i.e., ECDH) key exchange public key. C_PK2 represents the 'pk' output of the corresponding post-quantum KEM's 'KeyGen' at the client.
ここで、C_INIT は C_PK2 と C_PK1 の連結です (C_INIT = C_PK2 || C_PK1、ここで || は連結を表します)。C_PK1 と C_PK2 は、PQ/T ハイブリッド メカニズムの各鍵交換に使用される一時的なクライアント公開鍵を表します。通常、C_PK1 は従来の/古典的な (つまり ECDH) 鍵交換公開鍵を表します。C_PK2 は、クライアントでの対応するポスト量子 KEM の「KeyGen」の「pk」出力を表します。
Instead of SSH_MSG_KEXDH_REPLY [RFC4253] or SSH_MSG_KEX_ECDH_REPLY [RFC5656], the server sends:
SSH_MSG_KEXDH_REPLY [RFC4253] または SSH_MSG_KEX_ECDH_REPLY [RFC5656] の代わりに、サーバーは以下を送信します。
byte SSH_MSG_KEX_HYBRID_REPLY
string K_S, server's public host key
string S_REPLY
string the signature on the exchange hash
where S_REPLY is the concatenation of S_CT2 and S_PK1 (S_REPLY = S_CT2 || S_PK1). Typically, S_PK1 represents the ephemeral (EC)DH server public key. S_CT2 represents the ciphertext 'ct' output of the corresponding KEM's 'Encaps' algorithm generated by the server, which encapsulates a secret to the client's public key C_PK2. Before producing S_CT2, to prevent length extension attack attempts, the server MUST check that the length of the C_INIT is the sum of the expected length of each public key in the negotiated method, C_PK1 and C_PK2. It also MUST perform the encapsulation key checks defined in Section 7.2 of [FIPS203]. If any of these checks fail, the client MUST abort using a disconnect message (SSH_MSG_DISCONNECT) with a SSH_DISCONNECT_KEY_EXCHANGE_FAILED as the reason.
ここで、S_REPLY は S_CT2 と S_PK1 を連結したものです (S_REPLY = S_CT2 || S_PK1)。通常、S_PK1 は一時 (EC)DH サーバーの公開キーを表します。S_CT2 は、サーバーによって生成された、対応する KEM の「Encaps」アルゴリズムの暗号文「ct」出力を表し、クライアントの公開鍵 C_PK2 に対する秘密をカプセル化します。S_CT2 を生成する前に、長さ拡張攻撃の試みを防ぐために、サーバーは C_INIT の長さが、ネゴシエートされたメソッド C_PK1 と C_PK2 の各公開鍵の予想される長さの合計であることを確認しなければなりません (MUST)。また、[FIPS203] のセクション 7.2 で定義されているカプセル化キーのチェックも実行しなければなりません (MUST)。これらのチェックのいずれかが失敗した場合、クライアントは SSH_DISCONNECT_KEY_EXCHANGE_FAILED を理由とした切断メッセージ (SSH_MSG_DISCONNECT) を使用して中止しなければなりません (MUST)。
C_PK1, S_PK1, C_PK2, and S_CT2 are used to establish two shared secrets, K_CL and K_PQ. K_CL is the output from the classical ECDH exchange using C_PK1 and S_PK1. K_PQ is the post-quantum shared secret decapsulated from S_CT2. Before decapsulating, to prevent length extension attack attempts, the client MUST check that the length of the S_REPLY is the sum of the expected length of the traditional public key, S_PK1, and the ML-KEM ciphertext, S_CT2, in the negotiated method. The client MUST abort using a disconnect message (SSH_MSG_DISCONNECT) with a SSH_DISCONNECT_KEY_EXCHANGE_FAILED as the reason if the check fails or decapsulation fails for any other reason. K_CL and K_PQ are used together to generate the shared secret K according to Section 2.4.
C_PK1、S_PK1、C_PK2、および S_CT2 は、2 つの共有秘密 K_CL と K_PQ を確立するために使用されます。K_CL は、C_PK1 と S_PK1 を使用した従来の ECDH 交換からの出力です。K_PQ は、S_CT2 からカプセル化解除されたポスト量子共有秘密です。カプセル化を解除する前に、長さ拡張攻撃の試みを防ぐために、クライアントは S_REPLY の長さが、ネゴシエートされたメソッドでの従来の公開鍵 S_PK1 と ML-KEM 暗号文 S_CT2 の予想される長さの合計であることを確認しなければなりません (MUST)。チェックが失敗した場合、または他の理由でカプセル化解除が失敗した場合、クライアントは、理由として SSH_DISCONNECT_KEY_EXCHANGE_FAILED を指定した切断メッセージ (SSH_MSG_DISCONNECT) を使用して中止しなければなりません (MUST)。K_CL と K_PQ は、セクション 2.4 に従って共有秘密 K を生成するために一緒に使用されます。
For all method names, both the client and server MUST process the ECDH and X25519 public keys (C_PK1 and S_PK1) as described in Section 4 of [RFC5656] and Section 3 of [RFC8731], respectively, including validity and length checks and SSH disconnect messages if the checks fail.
すべてのメソッド名について、クライアントとサーバーの両方は、有効性と長さのチェックと、チェックが失敗した場合の SSH 切断メッセージを含めて、[RFC5656] のセクション 4 と [RFC8731] のセクション 3 で説明されているように、それぞれ ECDH および X25519 公開鍵 (C_PK1 および S_PK1) を処理しなければなりません (MUST)。
The message numbers 30-49 are key exchange method specific as specified in [RFC4250]. These numbers may be redefined by any key exchange method [RFC4253] without requiring an IANA registration process. This document defines the following key exchange message numbers:
メッセージ番号 30 ～ 49 は、[RFC4250] で指定されている鍵交換方式に固有のものです。これらの番号は、IANA 登録プロセスを必要とせずに、任意の鍵交換方法 [RFC4253] によって再定義できます。この文書では、次の鍵交換メッセージ番号を定義します。
#define SSH_MSG_KEX_HYBRID_INIT 30
#define SSH_MSG_KEX_HYBRID_REPLY 31
The PQ/T Hybrid key exchange method names defined in this document (to be used in SSH_MSG_KEXINIT [RFC4253]) are:
この文書で定義されている (SSH_MSG_KEXINIT [RFC4253] で使用される) PQ/T ハイブリッド鍵交換メソッド名は次のとおりです。
* mlkem768nistp256-sha256
* mlkem768nistp256-sha256
* mlkem1024nistp384-sha384
* mlkem1024nistp384-sha384
* mlkem768x25519-sha256
* mlkem768x25519-sha256
These instantiate the abstract PQ/T Hybrid key exchanges defined in Section 2.1.
これらは、セクション 2.1 で定義された抽象 PQ/T ハイブリッド鍵交換をインスタンス化します。
mlkem768nistp256-sha256 defines that the traditional client and server public keys C_PK1 and S_PK1 belong to the NIST P-256 curve [NIST-SP800-186]. The private and public keys are generated as described therein. The public keys are defined as octet strings for NIST P-256 as per [RFC5656]; point compression may be used. The K_CL shared secret is generated from the exchanged C_PK1 and S_PK1 public keys as defined in [RFC5656] (key agreement method ecdh-sha2-nistp256).
mlkem768nistp256-sha256 は、従来のクライアントとサーバーの公開鍵 C_PK1 および S_PK1 が NIST P-256 曲線 [NIST-SP800-186] に属することを定義しています。秘密鍵と公開鍵は、そこに記載されているように生成されます。公開鍵は、[RFC5656] に従って NIST P-256 のオクテット文字列として定義されます。ポイント圧縮が使用される場合があります。K_CL 共有秘密は、[RFC5656] (鍵合意方式 ecdh-sha2-nistp256) で定義されているように、交換された C_PK1 および S_PK1 公開鍵から生成されます。
The post-quantum C_PK2 and S_CT2 represent ML-KEM-768 public key and ciphertext from the client and server, respectively, which are encoded as octet strings. The K_PQ shared secret is decapsulated from the ciphertext S_CT2 using the client post-quantum KEM private key as defined in [FIPS203].
ポスト量子 C_PK2 と S_CT2 は、それぞれクライアントとサーバーからの ML-KEM-768 公開キーと暗号文を表し、オクテット文字列としてエンコードされます。K_PQ 共有秘密は、[FIPS203] で定義されているクライアントの量子後 KEM 秘密鍵を使用して暗号文 S_CT2 からカプセル化解除されます。
The HASH function used in the key exchange [RFC4253] is SHA-256 [NIST-SHA2] [RFC6234].
鍵交換 [RFC4253] で使用される HASH 関数は SHA-256 [NIST-SHA2] [RFC6234] です。
mlkem1024nistp384-sha384 defines that the traditional client and server public keys C_PK1 and S_PK1 belong to the NIST P-384 curve [NIST-SP800-186]. The private and public keys are generated as described therein. The public keys are defined as octet strings for NIST P-384 as per [RFC5656]; point compression may be used. The K_CL shared secret is generated from the exchanged C_PK1 and S_PK1 public keys as defined in [RFC5656] (key agreement method ecdh-sha2-nistp384).
mlkem1024nistp384-sha384 は、従来のクライアントとサーバーの公開鍵 C_PK1 および S_PK1 が NIST P-384 曲線 [NIST-SP800-186] に属することを定義しています。秘密鍵と公開鍵は、そこに記載されているように生成されます。公開鍵は、[RFC5656] に従って NIST P-384 のオクテット文字列として定義されます。ポイント圧縮が使用される場合があります。K_CL 共有秘密は、[RFC5656] (鍵合意方式 ecdh-sha2-nistp384) で定義されているように、交換された C_PK1 および S_PK1 公開鍵から生成されます。
The post-quantum C_PK2 and S_CT2 represent ML-KEM-1024 public key and ciphertext from the client and server, respectively, which are encoded as octet strings. The K_PQ shared secret is decapsulated from the ciphertext S_CT2 using the client post-quantum KEM private key as defined in [FIPS203].
ポスト量子 C_PK2 と S_CT2 は、それぞれクライアントとサーバーからの ML-KEM-1024 公開キーと暗号文を表し、オクテット文字列としてエンコードされます。K_PQ 共有秘密は、[FIPS203] で定義されているクライアントの量子後 KEM 秘密鍵を使用して暗号文 S_CT2 からカプセル化解除されます。
The HASH function used in the key exchange [RFC4253] is SHA-384 [NIST-SHA2] [RFC6234].
鍵交換 [RFC4253] で使用される HASH 関数は SHA-384 [NIST-SHA2] [RFC6234] です。
mlkem768x25519-sha256 defines that the traditional client and server public keys C_PK1 and S_PK1 belong to the Curve25519 curve [RFC7748]. Private and public keys are generated as described therein. The public keys are defined as strings of 32 bytes as per [RFC8731]. The K_CL shared secret is generated from the exchanged C_PK1 and S_PK1 public keys as defined in [RFC8731] (key agreement method curve25519-sha256).
mlkem768x25519-sha256 は、従来のクライアントとサーバーの公開鍵 C_PK1 および S_PK1 が Curve25519 曲線 [RFC7748] に属することを定義しています。秘密鍵と公開鍵は、そこに記載されているように生成されます。公開鍵は、[RFC8731] に従って 32 バイトの文字列として定義されます。K_CL 共有秘密は、[RFC8731] (鍵合意方式 Curve25519-sha256) で定義されているように、交換された C_PK1 および S_PK1 公開鍵から生成されます。
The post-quantum C_PK2 and S_CT2 represent ML-KEM-768 public key and ciphertext from the client and server, respectively, which are encoded as octet strings. The K_PQ shared secret is decapsulated from the ciphertext S_CT2 using the client post-quantum KEM private key as defined in [FIPS203].
ポスト量子 C_PK2 と S_CT2 は、それぞれクライアントとサーバーからの ML-KEM-768 公開キーと暗号文を表し、オクテット文字列としてエンコードされます。K_PQ 共有秘密は、[FIPS203] で定義されているクライアントのポスト量子 KEM 秘密鍵を使用して暗号文 S_CT2 からカプセル化解除されます。
The HASH function used in the key exchange [RFC4253] is SHA-256 [NIST-SHA2] [RFC6234].
鍵交換 [RFC4253] で使用される HASH 関数は SHA-256 [NIST-SHA2] [RFC6234] です。
The PQ/T Hybrid key exchange establishes K_CL and K_PQ from the ECDH and ML-KEM key exchanges, respectively. The shared secret, K, is the HASH output of the concatenation of the two shared secrets K_CL and K_PQ as:
PQ/T ハイブリッド鍵交換は、ECDH 鍵交換と ML-KEM 鍵交換からそれぞれ K_CL と K_PQ を確立します。共有秘密 K は、次の 2 つの共有秘密 K_CL と K_PQ を連結した HASH 出力です。
K = HASH(K_PQ || K_CL)
K = ハッシュ(K_PQ || K_CL)
This is similar, but not the same (for efficiency) logic as in TLS 1.3 [RFC9954]. In [RFC9954], the classical and post-quantum exchanged secrets are concatenated and used in the key schedule, whereas in this document they are concatenated and hashed before being used in SSH's key derivation methodology.
これは、TLS 1.3 [RFC9954] のロジックに似ていますが、(効率性の観点から) 同じではありません。[RFC9954] では、古典的およびポスト量子交換秘密は連結されて鍵スケジュールで使用されますが、この文書では、それらは SSH の鍵導出方法論で使用される前に連結されてハッシュされます。
The ECDH shared secret was traditionally encoded as an integer (mpint) as per [RFC4253], [RFC5656], and [RFC8731] and used in deriving the key. In this specification, the two shared secrets, K_PQ and K_CL, are fed into the hash function to derive K, but they are encoded as fixed-length byte arrays, not as integers. Byte arrays are defined in Section 5 of [RFC4251]. Specifically for K_CL, the conversion from mpint to a byte array is done by taking the mpint that the corresponding standalone key exchange method would have output and re-encoding it as a fixed-size (32 bytes for Curve25519 and secp256r1 or 48 bytes for secp384r1) byte array that is always big-endian.
ECDH 共有秘密は、伝統的に [RFC4253]、[RFC5656]、および [RFC8731] に従って整数 (mpint) としてエンコードされ、鍵の導出に使用されていました。この仕様では、2 つの共有秘密 K_PQ と K_CL がハッシュ関数に入力されて K が導出されますが、これらは整数ではなく固定長のバイト配列としてエンコードされます。バイト配列は [RFC4251] のセクション 5 で定義されています。特に K_CL の場合、mpint からバイト配列への変換は、対応するスタンドアロン鍵交換メソッドが出力する mpint を取得し、それを常にビッグエンディアンの固定サイズ (Curve25519 および secp256r1 の場合は 32 バイト、または secp384r1 の場合は 48 バイト) のバイト配列として再エンコードすることによって行われます。
The derivation of encryption keys MUST be done from the shared secret K according to Section 7.2 of [RFC4253] with a modification on the exchange hash H.
暗号鍵の導出は、[RFC4253] のセクション 7.2 に従って、交換ハッシュ H を変更して共有秘密 K から行われなければなりません (MUST)。
The PQ/T Hybrid key exchange hash H is the result of computing the HASH, where HASH is the hash algorithm specified in the named PQ/T Hybrid key exchange method name, over the concatenation of the following:
PQ/T ハイブリッド キー交換ハッシュ H は、次のものを連結して HASH を計算した結果です。HASH は、指定された PQ/T ハイブリッド キー交換メソッド名で指定されたハッシュ アルゴリズムです。
string V_C, client identification string (CR and LF excluded)
string V_S, server identification string (CR and LF excluded)
string I_C, payload of the client's SSH_MSG_KEXINIT
string I_S, payload of the server's SSH_MSG_KEXINIT
string K_S, server's public host key
string C_INIT, client message octet string
string S_REPLY, server message octet string
string K, SSH shared secret
K, the shared secret used in H, was traditionally encoded as an integer (mpint) as per [RFC4253], [RFC5656], and [RFC8731]. In this specification, K is the hash output of the two concatenated byte arrays (Section 2.4), which is not an integer. Thus, K is encoded as a string using the process described in Section 5 of [RFC4251] and is then fed along with other data in H to the key exchange method's HASH function to generate encryption keys.
H で使用される共有秘密である K は、伝統的に [RFC4253]、[RFC5656]、および [RFC8731] に従って整数 (mpint) としてエンコードされていました。この仕様では、K は 2 つの連結されたバイト配列 (セクション 2.4) のハッシュ出力であり、整数ではありません。したがって、K は [RFC4251] のセクション 5 で説明されているプロセスを使用して文字列としてエンコードされ、H 内の他のデータとともに鍵交換メソッドの HASH 関数に供給されて暗号化鍵が生成されます。
An SSH implementation adhering to [RFC4253] must be able to support packets with an uncompressed payload length of 32768 bytes or less and a total packet size of 35000 bytes or less (including 'packet_length', 'padding_length', 'payload', 'random padding', and 'mac'). These numbers represent what must be minimally supported by SSH applications. Although some post-quantum key exchange schemes could produce large messages, this document does not define method names (Section 2.3), which can lead to packets exceeding the minimally specified lengths in Section 6.1 of [RFC4253]. Thus, this document does not define new behavior for cases where a PQ/T Hybrid key exchange message causes a packet to exceed the minimally supported length.
[RFC4253] に準拠した SSH 実装は、非圧縮ペイロード長が 32768 バイト以下、合計パケット サイズが 35000 バイト以下 (「packet_length」、「padding_length」、「payload」、「random padding」、「mac」を含む) のパケットをサポートできなければなりません。これらの数値は、SSH アプリケーションが最低限サポートする必要があるものを表します。一部のポスト量子鍵交換スキームでは大きなメッセージが生成される可能性がありますが、この文書ではメソッド名 (セクション 2.3) が定義されていないため、[RFC4253] のセクション 6.1 で最低限指定されている長さを超えるパケットが発生する可能性があります。したがって、この文書では、PQ/T ハイブリッド鍵交換メッセージによってパケットがサポートされる最小長を超える場合の新しい動作は定義されません。
IANA has registered the following method names in the "Key Exchange Method Names" registry within the "Secure Shell (SSH) Protocol Parameters" registry group [IANA-SSH].
IANA は、「Secure Shell (SSH) Protocol Parameters」レジストリ グループ [IANA-SSH] 内の「Key Exchange Method Names」レジストリに次のメソッド名を登録しました。
+==========================+===========+=================+
| Method Name | Reference | OK to Implement |
+==========================+===========+=================+
| mlkem768nistp256-sha256 | RFC 10042 | SHOULD |
+--------------------------+-----------+-----------------+
| mlkem1024nistp384-sha384 | RFC 10042 | SHOULD |
+--------------------------+-----------+-----------------+
| mlkem768x25519-sha256 | RFC 10042 | SHOULD |
+--------------------------+-----------+-----------------+
Table 1: New Key Exchange Method Names
表 1: 新しい鍵交換メソッド名
The security considerations given in [RFC5656] and [RFC8731] also apply to the ECDH part of the P/T Hybrid key exchange schemes defined in this document.
[RFC5656] および [RFC8731] で示されているセキュリティ上の考慮事項は、この文書で定義されている P/T ハイブリッド鍵交換スキームの ECDH 部分にも適用されます。
As it is commonly done with (EC)DH keys today, generating an ephemeral key exchange keypair for ECDH and ML-KEM per connection is REQUIRED by this specification. Additionally, implementations MUST NOT reuse randomness in the generation of ML-KEM ciphertexts. As a reminder, the security properties of the protocol in this document, SSH itself, and the cryptographic algorithms used, including ML-KEM, depend on the availability and proper use of cryptographically secure random data. The generation of quality random numbers for the traditional and ML-KEM keypairs and the ML-KEM ciphertext can be difficult; see Section 3.3 of [FIPS203] for additional information around randomness generation for ML-KEM.
現在、(EC)DH 鍵で一般的に行われているように、接続ごとに ECDH および ML-KEM の一時鍵交換鍵ペアを生成することが、この仕様で必須です。さらに、実装は ML-KEM 暗号文の生成においてランダム性を再利用してはなりません (MUST NOT)。このドキュメントのプロトコル、SSH 自体、および ML-KEM を含む使用される暗号化アルゴリズムのセキュリティ特性は、暗号的に安全なランダム データの可用性と適切な使用に依存します。従来の鍵ペアと ML-KEM 鍵ペアおよび ML-KEM 暗号文の高品質な乱数の生成は困難な場合があります。ML-KEM のランダム性生成に関する追加情報については、[FIPS203] のセクション 3.3 を参照してください。
Implementations MUST use the encodings for K_PQ, K_CL, and K specified in this document to prevent potential side-channel attacks. The way a derived binary secret string is encoded (i.e., adding or removing zero bytes for encoding) before it is hashed may lead to a variable-length secret, which raises the potential for a side-channel attack. In broad terms, when the secret is longer, the hash function may need to process more blocks internally, which could determine the length of what is hashed. This could leak the most significant bit of the derived secret and/or allow detection of when the most significant bytes are zero. In some unfortunate circumstances, this has led to timing attacks, e.g., the Lucky Thirteen [LUCKY13] and Raccoon [RACCOON] attacks. In [RFC8731] and [RFC5656], the ECDH shared secrets were mpint and fixed-length integer encoded, respectively, which raised a potential for such side-channel attacks. This problem is addressed in this document by encoding K_PQ and K_CL as fixed-length byte arrays and K as a string.
実装では、潜在的なサイドチャネル攻撃を防ぐために、この文書で指定されている K_PQ、K_CL、および K のエンコーディングを使用しなければなりません (MUST)。派生バイナリ シークレット文字列をハッシュする前にエンコードする方法 (つまり、エンコード用のゼロ バイトの追加または削除) により、可変長のシークレットが生成される可能性があり、サイドチャネル攻撃の可能性が高まります。大まかに言うと、シークレットが長い場合、ハッシュ関数は内部でより多くのブロックを処理する必要がある可能性があり、それによってハッシュされる長さが決まる可能性があります。これにより、派生秘密の最上位ビットが漏洩したり、最上位バイトがいつゼロになるかを検出できる可能性があります。残念な状況では、これにより、ラッキー サーティーン [LUCKY13] 攻撃やラクーン [RACCOON] 攻撃などのタイミング攻撃が発生することがあります。[RFC8731] と [RFC5656] では、ECDH 共有秘密はそれぞれ mpint と固定長整数でエンコードされており、そのようなサイドチャネル攻撃の可能性が生じていました。この文書では、K_PQ と K_CL を固定長バイト配列としてエンコードし、K を文字列としてエンコードすることで、この問題に対処します。
[PQ-PROOF] and [PQ-PROOF2] contain proofs of security for PQ/T Hybrid key exchange schemes. [PQ-PROOF2] discusses how the key combination to derive K and the derivation of SSH symmetric keys in this document can be proven to be IND-CPA and IND-CCA2 secure with some assumptions. IND-CPA is achieved if we assume the HASH calls perform as a KDF, which is a reasonable assumption. IND-CCA2 security is achieved by assuming the HASH is a random oracle, which is a stronger assumption especially for variants of the SHA-2 family, which introduce length extension risks. To leverage a HASH that is more suitable as a random oracle, we could use SHAKE256 or introduce HMAC-SHA-256 as proposed in options (2b) and (2c) in Appendix A. This document uses SHA-2, which is ubiquitous, although it makes an IND-CCA2 proof need stronger assumptions because even SSH's traditional key derivation has not been proven to be IND-CCA2.
[PQ-PROOF] および [PQ-PROOF2] には、PQ/T ハイブリッド鍵交換スキームのセキュリティの証明が含まれています。[PQ-PROOF2] では、この文書で K を導出する鍵の組み合わせと SSH 対称鍵の導出が、いくつかの仮定の下で IND-CPA および IND-CCA2 の安全性を証明できる方法について説明しています。HASH 呼び出しが KDF として実行されると仮定すると、IND-CPA が達成されます。これは合理的な仮定です。IND-CCA2 セキュリティは、HASH がランダム オラクルであると仮定することによって実現されます。これは、特に長さ拡張のリスクをもたらす SHA-2 ファミリのバリアントにとってはより強力な仮定です。ランダム オラクルとしてより適切な HASH を利用するには、SHAKE256 を使用するか、付録 A のオプション (2b) および (2c) で提案されているように HMAC-SHA-256 を導入します。この文書では遍在する SHA-2 を使用していますが、SSH の従来の鍵導出でさえ IND-CCA2 であることが証明されていないため、IND-CCA2 の証明にはより強力な仮定が必要になります。
X25519, the traditional elliptic curve key exchange used in one of the PQ/T hybrid methods specified in this document, is generally considered easier to implement securely without side channels than its NIST counterparts (with P256 and P384). Historically, implementations of P256 and P384 have suffered various implementation issues, which have been addressed over time. Optimized X25119 implementations are also more efficient than P256 and P384. Thus, X25519 has seen more adoption than P256 and P384 across cryptographic use cases. NIST curves are sometimes preferred for regulatory compliance.
このドキュメントで指定されている PQ/T ハイブリッド方式の 1 つで使用される従来の楕円曲線鍵交換である X25519 は、一般に、NIST の対応物 (P256 および P384) よりもサイド チャネルなしで安全に実装するのが簡単であると考えられています。歴史的に、P256 と P384 の実装ではさまざまな実装上の問題が発生しましたが、時間の経過とともに解決されてきました。最適化された X25119 実装は、P256 や P384 よりも効率的です。したがって、X25519 は、暗号化のユースケース全体で P256 や P384 よりも多く採用されています。NIST 曲線は、規制への準拠のために好まれる場合があります。
[FIPS203] NIST, "Module-Lattice-Based Key-Encapsulation Mechanism
Standard", NIST FIPS 203, DOI 10.6028/NIST.FIPS.203, 13
August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.203.pdf>.
[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>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
Integration in the Secure Shell Transport Layer",
RFC 5656, DOI 10.17487/RFC5656, December 2009,
<https://www.rfc-editor.org/info/rfc5656>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[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>.
[RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure
Shell (SSH) Key Exchange Method Using Curve25519 and
Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020,
<https://www.rfc-editor.org/info/rfc8731>.
[CHEMPAT] Josefsson, S., "Chempat: Generic Instantiated PQ/T Hybrid
Key Encapsulation Mechanisms", Work in Progress, Internet-
Draft, draft-josefsson-chempat-05, 24 June 2026,
<https://datatracker.ietf.org/doc/html/draft-josefsson-
chempat-05>.
[IANA-SSH] IANA, "Secure Shell (SSH) Protocol Parameters",
<https://www.iana.org/assignments/ssh-parameters>.
[LUCKY13] Al Fardan, N.J. and K.G. 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, 2013,
<https://ieeexplore.ieee.org/
iel7/6547086/6547088/06547131.pdf>.
[NIST-SHA2]
NIST, "Secure Hash Standard (SHS)", NIST FIPS 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.
[NIST-SP800-186]
Chen, L., Moody, D., Randall, K., Regenscheid, A., and A.
Robinson, "Recommendations for Discrete Logarithm-based
Cryptography: Elliptic Curve Domain Parameters", National
Institute of Standards and Technology, NIST SP 800-186,
DOI 10.6028/NIST.SP.800-186, February 2023,
<https://doi.org/10.6028/NIST.SP.800-186>.
[NIST-SP-800-56C]
Barker, E., Chen, L., and R. Davis, "Recommendation for
Key-Derivation Methods in Key-Establishment Schemes",
National Institute of Standards and Technology, 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-133r2]
Barker, E., Roginsky, A., and R. Davis, "Recommendation
for Cryptographic Key Generation", National Institute of
Standards and Technology, NIST SP 800-133r2,
DOI 10.6028/NIST.SP.800-133r2, June 2020,
<https://doi.org/10.6028/NIST.SP.800-133r2>.
[NIST-SP-800-135]
Dang, Q., "Recommendation for Existing Application-
Specific Key Derivation Functions", National Institute of
Standards and Technology, NIST SP 800-135r1,
DOI 10.6028/NIST.SP.800-135r1, December 2011,
<https://doi.org/10.6028/NIST.SP.800-135r1>.
[NIST-SP-800-227]
Alagic, G., Barker, E., Chen, L., Dustin, D., Robinson,
A., Silberg, H., and N. Waller, "Recommendations for Key-
Encapsulation Mechanisms", National Institute of Standards
and Technology, NIST SP 800-227,
DOI 10.6028/NIST.SP.800-227, September 2025,
<https://doi.org/10.6028/NIST.SP.800-227>.
[NIST_PQ] NIST, "Post-Quantum Cryptography (PQC)", 5 August 2026,
<https://csrc.nist.gov/projects/post-quantum-
cryptography>.
[OAM-CONS] Claise, B., Clarke, J., Farrel, A., Barguil, S.,
Pignataro, C., and R. Chen, "Guidelines for Considering
Operations and Management in IETF Specifications", Work in
Progress, Internet-Draft, draft-ietf-opsawg-rfc5706bis-06,
12 August 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-opsawg-rfc5706bis-06>.
[PQ-PROOF] Campagna, M. and A. Petcher, "Security of Hybrid Key
Encapsulation", Cryptology ePrint Archive, Paper
2020/1364, 2020, <https://eprint.iacr.org/2020/1364>.
[PQ-PROOF2]
Petcher, A. and M. Campagna, "Security of Hybrid Key
Establishment using Concatenation", Cryptology ePrint
Archive, Paper 2023/972, 2023,
<https://eprint.iacr.org/2023/972>.
[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/>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250,
DOI 10.17487/RFC4250, January 2006,
<https://www.rfc-editor.org/info/rfc4250>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[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>.
[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>.
[RFC9954] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid Key
Exchange in TLS 1.3", RFC 9954, DOI 10.17487/RFC9954, July
2026, <https://www.rfc-editor.org/info/rfc9954>.
[RFC9958] Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
T., and M. Ounsworth, "Post-Quantum Cryptography for
Engineers", RFC 9958, DOI 10.17487/RFC9958, June 2026,
<https://www.rfc-editor.org/info/rfc9958>.
[XWING-KEM]
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>.
Other combiners to derive K and the SSH keys were considered while working on this document. These include:
このドキュメントの作業中に、K キーと SSH キーを導出する他の結合器が検討されました。これらには次のものが含まれます。
(1) K = K_PQ || K_CL. All SSH keys are derived from K as defined in Section 7.2 of [RFC4253].
(1) K = K_PQ ||K_CL。すべての SSH 鍵は、[RFC4253] のセクション 7.2 で定義されている K から派生します。
(2) All SSH keys are derived from K as defined in Section 7.2 of [RFC4253].
(2) すべての SSH 鍵は、[RFC4253] のセクション 7.2 で定義されている K から派生します。
(a) K = HASH(K_PQ, K_CL). This is the option adopted in this specification.
(a) K = ハッシュ(K_PQ, K_CL)。これがこの仕様で採用されているオプションです。
(b) K = HMAC-HASH(K_PQ, K_CL)
(b) K = HMAC-HASH(K_PQ, K_CL)
(c) K = HMAC-HASH(0, K_PQ || K_CL)
(c) K = HMAC-HASH(0, K_PQ || K_CL)
(3) K = HKDF-HASH_Extract(0, K_PQ || K_CL). SSH keys are now derived from K using HKDF-HASH(K, H || session_id, 6*sizeof(HASH)).
(3) K = HKDF-HASH_Extract(0, K_PQ || K_CL)。SSH キーは、HKDF-HASH(K, H || session_id, 6*sizeof(HASH)) を使用して K から導出されるようになりました。
Option (3) follows the Extract-and-Expand logic described in [NIST-SP-800-56C]. It deviates from existing SSH key derivation significantly and might be viewed as too far from the current SSH design. It probably would be a good approach for SSH to move from basic hashing everywhere to use proper KDFs with extract/expand, but that should be a separate effort.
オプション (3) は、[NIST-SP-800-56C] で説明されている抽出と展開のロジックに従います。これは既存の SSH キーの派生から大幅に逸脱しており、現在の SSH 設計からかけ離れていると見なされる可能性があります。おそらく、SSH がどこでも基本的なハッシュから抽出/展開で適切な KDF を使用するように移行するのは良いアプローチでしょうが、それは別の取り組みである必要があります。
We also considered combiners like the ones proposed in [CHEMPAT] and [XWING-KEM]. [XWING-KEM] has a separate IND-CCA2 security proof. Although such combiners may be proven IND-CCA2 secure, to be IND-CCA2, the SSH key derivation would still require the assumptions laid out in [PQ-PROOF2] and discussed in Section 5.
[CHEMPAT] や [XWING-KEM] で提案されているような結合器も検討しました。[XWING-KEM] には、別個の IND-CCA2 セキュリティ証明があります。このようなコンバイナは IND-CCA2 の安全性が証明されている可能性がありますが、IND-CCA2 であるためには、SSH 鍵の導出には [PQ-PROOF2] で説明され、セクション 5 で説明されている仮定が依然として必要になります。
[NIST-SP-800-56C] and [NIST-SP-800-135] give NIST recommendations for key derivation methods in key exchange protocols. Some PQ/T Hybrid combinations may combine the shared secret from a NIST-approved algorithm (e.g., ECDH using the nistp256/secp256r1 curve or ML-KEM) with a shared secret from a non-approved algorithm (e.g., X25519). [NIST-SP-800-227] lists simple concatenation as an approved way of producing a PQ/T Hybrid shared secret in which one of the constituent secrets is from an approved algorithm (i.e., secp256r1, secp384r1, ML-KEM) and using it in a key derivation/combination method approved by [NIST-SP-800-56C] or [NIST-SP-800-133r2]. Although the SSH key derivation function does not follow [NIST-SP-800-56C] or [NIST-SP-800-133r2], it is approved by [NIST-SP-800-135]. This method is the same used in this document to derive SSH keys from the quantum-resistant shared secret. Thus, the SSH key combiner in this document appears to be FIPS-approved although it is not specifically called out in [NIST-SP-800-227].
[NIST-SP-800-56C] および [NIST-SP-800-135] は、鍵交換プロトコルにおける鍵導出方法に関する NIST 推奨事項を示しています。一部の PQ/T ハイブリッドの組み合わせでは、NIST 承認アルゴリズム (nistp256/secp256r1 曲線を使用する ECDH または ML-KEM など) の共有秘密と、未承認アルゴリズム (X25519 など) の共有秘密を組み合わせる場合があります。[NIST-SP-800-227] は、構成秘密の 1 つが承認されたアルゴリズム (つまり、secp256r1、secp384r1、ML-KEM) からのものである PQ/T ハイブリッド共有秘密を生成する承認された方法として単純連結をリストし、それを [NIST-SP-800-56C] によって承認された鍵導出/組み合わせ方法で使用します。[NIST-SP-800-133r2]。SSH 鍵導出機能は [NIST-SP-800-56C] または [NIST-SP-800-133r2] に準拠していませんが、[NIST-SP-800-135] によって承認されています。この方法は、このドキュメントで耐量子性共有秘密から SSH キーを導出するために使用されているものと同じです。したがって、この文書の SSH 鍵結合器は、[NIST-SP-800-227] では特に言及されていませんが、FIPS によって承認されているように見えます。
The authors want to thank Gerardo Ravago from AWS for implementing this document and finding issues. We also want to thank Damien Miller and Markus Friedl for their feedback and for implementing some of the SSH key exchange methods in this document in OpenSSH. Special acknowledgements go to Simon Tatham from Putty, Loganaden Velvindron, John Mattsson, Simon Josefsson, and Watson Ladd for their valuable suggestions.
著者らは、このドキュメントを実装し、問題を発見してくれた AWS の Gerardo Ravago に感謝したいと思います。また、フィードバックをいただき、このドキュメントの SSH キー交換メソッドの一部を OpenSSH に実装してくださった Damien Miller 氏と Markus Friedl 氏にも感謝します。貴重なご提案をいただいた Putty の Simon Tatham、Loganaden Velvindron、John Mattsson、Simon Josefsson、Watson Ladd に特別な謝意を表します。
Panos Kampanakis
AWS
Email: kpanos@amazon.com
Douglas Stebila
University of Waterloo
Email: dstebila@uwaterloo.ca
Torben Hansen
AWS
Email: htorben@amazon.com