RFC 10042: Post-Quantum/Traditional Hybrid Key Exchange with the Module-Lattice-Based Key-Encapsulation Mechanism for Use in SSH | RFC Editor

Abstract

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 https://www.rfc-editor.org/info/rfc10042.¶

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 (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.¶

1. Introduction

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

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].¶

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

In the context of the [NIST_PQ], 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 [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.¶

2. PQ/T Hybrid Key Exchange

3. Message Size

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

4. 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 [IANA-SSH].¶

5. Security Considerations

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

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

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

[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.¶

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

6. References

Appendix A. 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 Section 7.2 of [RFC4253].¶

(2)

All SSH keys are derived from K as defined in Section 7.2 of [RFC4253].¶

(a)

K = HASH(K_PQ, K_CL). This is the option adopted in this specification.¶

(b)

K = HMAC-HASH(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)).¶

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

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

Appendix B. FIPS

[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].¶

Acknowledgements

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

Authors' Addresses