Secure Shell (SSH) Post-Quantum/Traditional Hybrid Key Exchange Methods Using Scloud+
draft-prabel-ssh-scloudplus-kex-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Lucas Prabel , 唐毅 | ||
| Last updated | 2026-10-15 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-prabel-ssh-scloudplus-kex-00
Network Working Group L. Prabel
Internet-Draft Y. Tang
Intended status: Informational Huawei
Expires: 18 April 2027 15 October 2026
Secure Shell (SSH) Post-Quantum/Traditional Hybrid Key Exchange Methods
Using Scloud+
draft-prabel-ssh-scloudplus-kex-00
Abstract
This document defines four Post-Quantum/Traditional (PQ/T) hybrid key
exchange methods for the Secure Shell (SSH) protocol. They combine
the Scloud+ key-encapsulation mechanism, whose security relies on the
unstructured Learning With Errors (LWE) problem, with Elliptic Curve
Diffie-Hellman over the NIST P-384 and P-521 curves.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 April 2027.
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.
Prabel & Tang Expires 18 April 2027 [Page 1]
Internet-Draft Scloud+ Hybrid Key Exchange for SSH October 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scloud+ . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. PQ/T Hybrid Key Exchange . . . . . . . . . . . . . . . . . . 3
3.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 4
3.2. Message Numbers . . . . . . . . . . . . . . . . . . . . . 5
3.3. Method Names . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Shared Secret K . . . . . . . . . . . . . . . . . . . . . 6
3.5. Exchange Hash and Key Derivation . . . . . . . . . . . . 6
4. Message Size . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Key exchange in SSH [RFC4251] is today based on Elliptic Curve
Diffie-Hellman (ECDH) [RFC5656] [RFC8731], which a Cryptographically
Relevant Quantum Computer (CRQC) would break. Because recorded
sessions could then be decrypted, SSH key exchange needs post-quantum
protection before such a computer exists.
Post-quantum algorithms being less mature than ECDH in their design
and implementation, a hybrid key exchange combines a post-quantum KEM
with ECDH, so that the session keys stay secure as long as one of the
two components is not broken.
[RFC9941] and [RFC10042] address this with PQ/T hybrid [RFC9794]
methods built on Streamlined NTRU Prime and ML-KEM, two KEMs based on
structured lattices. This document adds methods built on Scloud+, a
PQ KEM based on unstructured LWE. Message format, shared secret
combination and exchange hash are similar to the ones of [RFC10042].
Only the post-quantum KEM and the elliptic curves differ.
Prabel & Tang Expires 18 April 2027 [Page 2]
Internet-Draft Scloud+ Hybrid Key Exchange for SSH October 2026
1.1. Scloud+
Scloud+ [SCLOUDPLUS] is one of the Round 1 KEM candidates of the
Next-generation Commercial Cryptographic Algorithms Program (NGCC)
run by the Institute of Commercial Cryptography Standards [NGCC].
The submission package contains the specification, reference and
optimized implementations, and known-answer tests. An earlier
version of the design was published in [SCLOUDPLUS-SSR24]; its
parameters differ from those of the NGCC submission, which are the
ones used here.
Scloud+ does not use a ring or module structure, so its security does
not depend on the hardness of structured lattice problems. This
makes it a conservative choice: attacks that would exploit the
algebraic structure of ML-KEM or NTRU Prime do not apply to it. The
price is much larger public keys and ciphertexts than ML-KEM.
Ternary secrets and Barnes-Wall lattice codes make them smaller than
those of FrodoKEM [I-D.longa-cfrg-frodokem], another unstructured LWE
KEM. The KEM is obtained from an IND-CPA encryption scheme with the
Fujisaki-Okamoto transform with implicit rejection, and targets IND-
CCA2 security.
This document uses the Scloud+-192 and Scloud+-256 parameter sets,
each in an AES and a SHAKE variant. The two variants only differ in
how the public matrix A is expanded from its seed: AES-128 in counter
mode for the AES variant, SHAKE-128 for the SHAKE variant. All other
internal functions use SHAKE-256 in both. Sizes are identical, but
the variants do not interoperate.
In this document, Scloud+ KeyGen, Encaps and Decaps refer to the key
generation, encapsulation and decapsulation algorithms of
[SCLOUDPLUS].
2. Conventions and Definitions
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.
The byte and string data types are used as defined in Section 5 of
[RFC4251]. || denotes concatenation.
3. PQ/T Hybrid Key Exchange
Prabel & Tang Expires 18 April 2027 [Page 3]
Internet-Draft Scloud+ Hybrid Key Exchange for SSH October 2026
3.1. Protocol Messages
The client sends SSH_MSG_KEX_HYBRID_INIT instead of
SSH_MSG_KEX_ECDH_INIT [RFC5656]:
byte SSH_MSG_KEX_HYBRID_INIT
string C_INIT
C_INIT = C_PK2 || C_PK1, where C_PK2 is the public key output by
Scloud+ KeyGen at the client and C_PK1 is the client's ephemeral ECDH
public key.
The server sends SSH_MSG_KEX_HYBRID_REPLY instead of
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
S_REPLY = S_CT2 || S_PK1, where S_CT2 is the ciphertext output by
Scloud+ Encaps on C_PK2 and S_PK1 is the server's ephemeral ECDH
public key.
The ECDH public keys are encoded as octet strings as in [RFC5656], in
the uncompressed form of Section 2.3.3 of [SEC1]. Compressed points
MUST NOT be sent, so that C_INIT and S_REPLY have a fixed length for
each method.
Before running Encaps, the server MUST check that C_INIT has the
length given in Table 2 for the negotiated method. Before running
Decaps, the client MUST do the same for S_REPLY. Both parties MUST
validate the received ECDH public key as described in Section 4 of
[RFC5656]. If one of these checks fails, the party MUST disconnect
with SSH_DISCONNECT_KEY_EXCHANGE_FAILED. No validation of the
Scloud+ public key or ciphertext is required beyond these length
checks.
K_CL is the ECDH shared secret computed from C_PK1 and S_PK1. K_PQ
is the Scloud+ shared secret, output by Encaps at the server and by
Decaps of S_CT2 at the client.
The rest of the exchange follows Section 4 of [RFC5656]: the server
signs the exchange hash H with its host key, and the client verifies
the host key and the signature.
Prabel & Tang Expires 18 April 2027 [Page 4]
Internet-Draft Scloud+ Hybrid Key Exchange for SSH October 2026
3.2. Message Numbers
Message numbers 30 to 49 are specific to each key exchange method
[RFC4250] and need no IANA registration. As in [RFC10042], this
document uses:
#define SSH_MSG_KEX_HYBRID_INIT 30
#define SSH_MSG_KEX_HYBRID_REPLY 31
3.3. Method Names
The methods defined in this document are listed in Table 1. The ECDH
part uses the curve as in [RFC5656] (methods ecdh-sha2-nistp384 and
ecdh-sha2-nistp521). HASH is the hash function used for K, for the
exchange hash H and for key derivation.
+================================+===============+==========+=======+
| Method name | Scloud+ | ECDH |HASH |
| | parameter | curve | |
| | set | | |
+================================+===============+==========+=======+
| scloudp192aesnistp384-sha384 | Scloud+-192, | nistp384 |SHA-384|
| | AES | | |
+--------------------------------+---------------+----------+-------+
| scloudp192shakenistp384-sha384 | Scloud+-192, | nistp384 |SHA-384|
| | SHAKE | | |
+--------------------------------+---------------+----------+-------+
| scloudp256aesnistp521-sha512 | Scloud+-256, | nistp521 |SHA-512|
| | AES | | |
+--------------------------------+---------------+----------+-------+
| scloudp256shakenistp521-sha512 | Scloud+-256, | nistp521 |SHA-512|
| | SHAKE | | |
+--------------------------------+---------------+----------+-------+
Table 1: PQ/T hybrid key exchange methods
SHA-384 and SHA-512 are defined in [RFC6234].
Table 2 gives the length in bytes of the values exchanged and
derived. It does not depend on the AES or SHAKE variant.
Prabel & Tang Expires 18 April 2027 [Page 5]
Internet-Draft Scloud+ Hybrid Key Exchange for SSH October 2026
+=========+===========================+===========================+
| Value | Scloud+-192 with nistp384 | Scloud+-256 with nistp521 |
+=========+===========================+===========================+
| C_PK2 | 11456 | 16296 |
+---------+---------------------------+---------------------------+
| C_PK1 | 97 | 133 |
+---------+---------------------------+---------------------------+
| C_INIT | 11553 | 16429 |
+---------+---------------------------+---------------------------+
| S_CT2 | 12645 | 17925 |
+---------+---------------------------+---------------------------+
| S_PK1 | 97 | 133 |
+---------+---------------------------+---------------------------+
| S_REPLY | 12742 | 18058 |
+---------+---------------------------+---------------------------+
| K_PQ | 24 | 32 |
+---------+---------------------------+---------------------------+
| K_CL | 48 | 66 |
+---------+---------------------------+---------------------------+
| K | 48 | 64 |
+---------+---------------------------+---------------------------+
Table 2: Lengths in bytes
3.4. Shared Secret K
The shared secret K is computed as:
K = HASH(K_PQ || K_CL)
Both inputs are fixed-length byte arrays and are not encoded as
mpint. K_PQ is the Scloud+ shared secret as output by Encaps or
Decaps. K_CL is the x-coordinate of the shared ECDH point, which
[RFC5656] encodes as an mpint, written instead as a big-endian byte
array of fixed length (48 bytes for nistp384, 66 bytes for nistp521).
This is the construction of Section 2.4 of [RFC10042].
3.5. Exchange Hash and Key Derivation
The exchange hash H is computed with HASH over:
Prabel & Tang Expires 18 April 2027 [Page 6]
Internet-Draft Scloud+ Hybrid Key Exchange for SSH October 2026
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 is encoded as a string, not as an mpint. Encryption keys MUST be
derived from K and H as specified in Section 7.2 of [RFC4253].
4. Message Size
[RFC4253] requires implementations to support packets with an
uncompressed payload of up to 32768 bytes and a total size of up to
35000 bytes. With the lengths of Table 2, SSH_MSG_KEX_HYBRID_INIT
stays within these limits. SSH_MSG_KEX_HYBRID_REPLY also stays
within them with the host key algorithms in common use today. A host
key algorithm with very large keys or signatures could push it over
the limit. This document does not define behavior for that case.
5. IANA Considerations
IANA is requested to add the following entries to the "Key Exchange
Method Names" registry within the "Secure Shell (SSH) Protocol
Parameters" registry group [IANA-SSH]:
+================================+===============+=================+
| Method Name | Reference | OK to Implement |
+================================+===============+=================+
| scloudp192aesnistp384-sha384 | This document | MAY |
+--------------------------------+---------------+-----------------+
| scloudp192shakenistp384-sha384 | This document | MAY |
+--------------------------------+---------------+-----------------+
| scloudp256aesnistp521-sha512 | This document | MAY |
+--------------------------------+---------------+-----------------+
| scloudp256shakenistp521-sha512 | This document | MAY |
+--------------------------------+---------------+-----------------+
Table 3: New key exchange method names
6. Security Considerations
The security considerations of [RFC4251] and [RFC5656] apply, as does
the discussion of the combiner and of the shared secret encoding in
Section 5 of [RFC10042].
Prabel & Tang Expires 18 April 2027 [Page 7]
Internet-Draft Scloud+ Hybrid Key Exchange for SSH October 2026
Scloud+ has not been standardized and is still under evaluation
[NGCC]. If Scloud+ were broken, the methods defined here would
remain as strong as ECDH on the same curve.
Each key exchange MUST use fresh ephemeral key pairs for ECDH and
Scloud+, generated with a cryptographically secure random number
generator.
7. References
7.1. Normative References
[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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/rfc8174>.
[SCLOUDPLUS]
Wang, A., Zheng, Z., Zhao, C., Tang, Y., Qiu, Z., and C.
Mu, "Scloud+ Algorithm Specifications and Supporting
Documentation", Round 1 submission to the Next-generation
Commercial Cryptographic Algorithms Program (NGCC), 30
April 2026,
<https://www.niccs.org.cn/niccs/Round1Additional/pc/
content/content_2101560881269264384.html>.
Prabel & Tang Expires 18 April 2027 [Page 8]
Internet-Draft Scloud+ Hybrid Key Exchange for SSH October 2026
[SEC1] Standards for Efficient Cryptography Group, "SEC 1:
Elliptic Curve Cryptography", Version 2.0, May 2009,
<https://www.secg.org/sec1-v2.pdf>.
7.2. Informative References
[I-D.longa-cfrg-frodokem]
Longa, P., Bos, J. W., Ehlen, S., and D. Stebila,
"FrodoKEM: key encapsulation from learning with errors",
Work in Progress, Internet-Draft, draft-longa-cfrg-
frodokem-03, 22 June 2026,
<https://datatracker.ietf.org/doc/html/draft-longa-cfrg-
frodokem-03>.
[IANA-SSH] IANA, "Secure Shell (SSH) Protocol Parameters", n.d.,
<https://www.iana.org/assignments/ssh-parameters>.
[NGCC] Institute of Commercial Cryptography Standards (ICCS),
"Next-generation Commercial Cryptographic Algorithms
Program (NGCC): Round 1 Candidates, Public-Key
Cryptographic Algorithms", September 2026,
<https://www.niccs.org.cn/niccs/Round1Additional/pc/
list.html>.
[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/rfc/rfc4250>.
[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/rfc/rfc8731>.
[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/rfc/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/rfc/rfc9941>.
Prabel & Tang Expires 18 April 2027 [Page 9]
Internet-Draft Scloud+ Hybrid Key Exchange for SSH October 2026
[RFC10042] Kampanakis, P., Stebila, D., and T. Hansen, "Post-Quantum/
Traditional Hybrid Key Exchange with the Module-Lattice-
Based Key-Encapsulation Mechanism for Use in SSH",
RFC 10042, DOI 10.17487/RFC10042, August 2026,
<https://www.rfc-editor.org/rfc/rfc10042>.
[SCLOUDPLUS-SSR24]
Wang, A., Zheng, Z., Zhao, C., Qiu, Z., Zeng, G., Yuan,
Y., Mu, C., and X. Wang, "Scloud+: An Efficient LWE-Based
KEM Without Ring/Module Structure", Security
Standardisation Research (SSR 2024), LNCS 15559, pp.
147-174, Springer, DOI 10.1007/978-3-031-87541-0_7, 2025,
<https://doi.org/10.1007/978-3-031-87541-0_7>.
Appendix A. Test Vectors
Test vectors will be provided in a future version of this document.
Known-answer tests for Scloud+ itself are part of the NGCC submission
package [SCLOUDPLUS].
Acknowledgments
This document follows the structure of [RFC10042] and [RFC9941].
Authors' Addresses
Lucas Prabel
Huawei
Email: lucas.prabel@huawei.com
Tang Yi
Huawei
Email: tangyi72@huawei.com
Prabel & Tang Expires 18 April 2027 [Page 10]