AWS

kpanos@amazon.com

University of Waterloo

dstebila@uwaterloo.ca

AWS

htorben@amazon.com

SEC sshm post-quantum SSH 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.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. 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. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () 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.

Table of Contents

• .  Introduction
  • .  Requirements Language
• .  PQ/T Hybrid Key Exchange
  • .  PQ/T Hybrid Key Exchange Method Abstraction
  • .  PQ/T Hybrid Key Exchange Message Numbers
  • .  PQ/T Hybrid Key Exchange Method Names
    • .  mlkem768nistp256-sha256
    • .  mlkem1024nistp384-sha384
    • .  mlkem768x25519-sha256
  • .  Shared Secret K
  • .  Key Derivation
• .  Message Size
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• .  Other Combiners
• .  FIPS
• Acknowledgements
• Authors' Addresses

Introduction Secure Shell (SSH) performs key establishment using key exchange methods based on Elliptic Curve Diffie-Hellman (ECDH) style schemes defined in and . The cryptographic security of these key exchanges relies on certain instances of the discrete logarithm problem being computationally infeasible to solve for adversaries. 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 . This document addresses the problem by extending the SSH transport layer protocol key exchange () with Post-Quantum Traditional (PQ/T) Hybrid key exchange methods . It follows the migration considerations laid out in . 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. and contain proofs of security for such PQ/T Hybrid key exchange schemes. In the context of the , key exchange algorithms are formulated as Key-Encapsulation Mechanisms (KEMs), which consist of three algorithms:

'KeyGen() -> (pk, sk)':

A probabilistic key generation algorithm, which generates a public key 'pk' and a secret key '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'.

'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.

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. The post-quantum KEM used in this document is the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). ML-KEM was standardized in 2024 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 , which uses a different quantum-resistant KEM.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

PQ/T Hybrid Key Exchange

PQ/T Hybrid Key Exchange Method Abstraction 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 . In a PQ/T Hybrid key exchange, instead of SSH_MSG_KEXDH_INIT or SSH_MSG_KEX_ECDH_INIT , the client sends: 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. Instead of SSH_MSG_KEXDH_REPLY or SSH_MSG_KEX_ECDH_REPLY , the server sends: 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 . 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. 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 . 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 and , respectively, including validity and length checks and SSH disconnect messages if the checks fail.

PQ/T Hybrid Key Exchange Message Numbers The message numbers 30-49 are key exchange method specific as specified in . These numbers may be redefined by any key exchange method without requiring an IANA registration process. This document defines the following key exchange message numbers: #define SSH_MSG_KEX_HYBRID_INIT 30 #define SSH_MSG_KEX_HYBRID_REPLY 31

PQ/T Hybrid Key Exchange Method Names The PQ/T Hybrid key exchange method names defined in this document (to be used in SSH_MSG_KEXINIT ) are:

• mlkem768nistp256-sha256
• mlkem1024nistp384-sha384
• mlkem768x25519-sha256

These instantiate the abstract PQ/T Hybrid key exchanges defined in .

mlkem768nistp256-sha256 mlkem768nistp256-sha256 defines that the traditional client and server public keys C_PK1 and S_PK1 belong to the NIST P-256 curve . The private and public keys are generated as described therein. The public keys are defined as octet strings for NIST P-256 as per ; 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 (key agreement method ecdh-sha2-nistp256). 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 . The HASH function used in the key exchange is SHA-256 .

mlkem1024nistp384-sha384 mlkem1024nistp384-sha384 defines that the traditional client and server public keys C_PK1 and S_PK1 belong to the NIST P-384 curve . The private and public keys are generated as described therein. The public keys are defined as octet strings for NIST P-384 as per ; 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 (key agreement method ecdh-sha2-nistp384). 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 . The HASH function used in the key exchange is SHA-384 .

mlkem768x25519-sha256 mlkem768x25519-sha256 defines that the traditional client and server public keys C_PK1 and S_PK1 belong to the Curve25519 curve . Private and public keys are generated as described therein. The public keys are defined as strings of 32 bytes as per . The K_CL shared secret is generated from the exchanged C_PK1 and S_PK1 public keys as defined in (key agreement method curve25519-sha256). 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 . The HASH function used in the key exchange is SHA-256 .

Shared Secret K 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:

• K = HASH(K_PQ || K_CL)

This is similar, but not the same (for efficiency) logic as in TLS 1.3 . In , 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. The ECDH shared secret was traditionally encoded as an integer (mpint) as per , , and 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 . 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.

Key Derivation The derivation of encryption keys MUST be done from the shared secret K according to with a modification on the exchange hash H. 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: 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 , , and . In this specification, K is the hash output of the two concatenated byte arrays (), which is not an integer. Thus, K is encoded as a string using the process described in and is then fed along with other data in H to the key exchange method's HASH function to generate encryption keys.

Message Size An SSH implementation adhering to 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 (), which can lead to packets exceeding the minimally specified lengths in . 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.

IANA Considerations IANA has registered the following method names in the "Key Exchange Method Names" registry within the "Secure Shell (SSH) Protocol Parameters" registry group . New 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

Security Considerations The security considerations given in and also apply to the ECDH part of the P/T Hybrid key exchange schemes defined in this document. 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 for additional information around randomness generation for ML-KEM. 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 and Raccoon attacks. In and , 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. and contain proofs of security for PQ/T Hybrid key exchange schemes. 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 . 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. 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.

References Normative References National Institute of Standards and Technology In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. [STANDARDS-TRACK] The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK] This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. [STANDARDS-TRACK] Federal Information Processing Standard, FIPS RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the specification for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol. Informative References This document specify Chempat as a generic family of instantiated Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange Methods (KEMs). The goal is to provide a generic combiner construct that can be analysed separately for security assurance, and to offer concrete instantiated algorithms for integration into protocol and implementations. Identified instances are provided based on some combinations of traditional Diffie-Hellman key agreement using curves P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 and brainpoolP512 combined with post quantum methods ML-KEM-768, ML-KEM- 1024, Streamlined NTRU Prime sntrup761, Classic McEliece and FrodoKEM. Work in Progress IANA 2013 IEEE Symposium on Security and Privacy, pp. 526-540 National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology NIST Everything OPS & Arrcus Cisco Old Dog Consulting Nokia Blue Fern Consulting ZTE New Protocols and Protocol Extensions are best designed with due consideration of the functionality needed to operate and manage them. Retrofitting operations and management considerations is suboptimal. The purpose of this document is to provide guidance to authors and reviewers on what operational and management aspects should be addressed when writing documents in the IETF Stream that document a specification for New Protocols or Protocol Extensions or describe their use. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also updates RFC 2360 to obsolete mandatory MIB creation. Finally, it introduces a requirement to include an "Operational Considerations" section in new RFCs in the IETF Stream that define New Protocols or Protocol Extensions or describe their use (including relevant YANG Models), while providing an escape clause if no new considerations are identified. Work in Progress Cryptology ePrint Archive, Paper 2020/1364 Cryptology ePrint Archive, Paper 2023/972 This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents. [STANDARDS-TRACK] This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. This document describes a widely deployed hybrid key exchange method in the Secure Shell (SSH) protocol that is based on Streamlined NTRU Prime sntrup761 and X25519 with SHA-512. 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. 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. SandboxAQ MPI-SP & Radboud University Cloudflare This memo defines X-Wing, a general-purpose post-quantum/traditional hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML- KEM-768. Work in Progress

Other Combiners Other combiners to derive K and the SSH keys were considered while working on this document. These include:

1. K = K_PQ || K_CL. All SSH keys are derived from K as defined in .
2. All SSH keys are derived from K as defined in .
   1. K = HASH(K_PQ, K_CL). This is the option adopted in this specification.
   2. K = HMAC-HASH(K_PQ, K_CL)
   3. 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)).

Option (3) follows the Extract-and-Expand logic described in . 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. We also considered combiners like the ones proposed in and . 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 and discussed in .

FIPS and 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). 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 or . Although the SSH key derivation function does not follow or , it is approved by . 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 .

Acknowledgements The authors want to thank from AWS for implementing this document and finding issues. We also want to thank and for their feedback and for implementing some of the SSH key exchange methods in this document in OpenSSH. Special acknowledgements go to from Putty, , , , and for their valuable suggestions.

Authors' Addresses AWS

kpanos@amazon.com

University of Waterloo

dstebila@uwaterloo.ca

AWS

htorben@amazon.com