| Internet-Draft | Scloud+ Hybrid Key Exchange for SSH | October 2026 |
| Prabel & Tang | Expires 18 April 2027 | [Page] |
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.¶
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 (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.¶
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.¶
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].¶
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.¶
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.¶
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¶
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+ parameter set | ECDH curve | HASH |
|---|---|---|---|
| scloudp192aesnistp384-sha384 | Scloud+-192, AES | nistp384 | SHA-384 |
| scloudp192shakenistp384-sha384 | Scloud+-192, SHAKE | nistp384 | SHA-384 |
| scloudp256aesnistp521-sha512 | Scloud+-256, AES | nistp521 | SHA-512 |
| scloudp256shakenistp521-sha512 | Scloud+-256, SHAKE | nistp521 | SHA-512 |
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.¶
| 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 |
The exchange hash H is computed with HASH over:¶
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].¶
[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.¶
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 |
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].¶
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.¶
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].¶
This document follows the structure of [RFC10042] and [RFC9941].¶