]> Huawei

lucas.prabel@huawei.com

Huawei

tangyi72@huawei.com

Security ssh key exchange post-quantum hybrid Scloud+ 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.

Introduction Key exchange in SSH is today based on Elliptic Curve Diffie-Hellman (ECDH) , 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. and address this with PQ/T hybrid 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 . Only the post-quantum KEM and the elliptic curves differ.

Scloud+ Scloud+ 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 . The submission package contains the specification, reference and optimized implementations, and known-answer tests. An earlier version of the design was published in ; 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 , 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 .

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 when, and only when, they appear in all capitals, as shown here. The byte and string data types are used as defined in . || denotes concatenation.

PQ/T Hybrid Key Exchange

Protocol Messages The client sends SSH_MSG_KEX_HYBRID_INIT instead of SSH_MSG_KEX_ECDH_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 : 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 , in the uncompressed form of Section 2.3.3 of . 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 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 . 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 : the server signs the exchange hash H with its host key, and the client verifies the host key and the signature.

Message Numbers Message numbers 30 to 49 are specific to each key exchange method and need no IANA registration. As in , this document uses:

Method Names The methods defined in this document are listed in . The ECDH part uses the curve as in (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. PQ/T hybrid key exchange methods

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 . gives the length in bytes of the values exchanged and derived. It does not depend on the AES or SHAKE variant. Lengths in bytes

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

Shared Secret K The shared secret K is computed as: 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 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 .

Exchange Hash and Key Derivation The exchange hash H is computed with HASH over: K is encoded as a string, not as an mpint. Encryption keys MUST be derived from K and H as specified in .

Message Size 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 , 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 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 : New key exchange method names

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

Security Considerations The security considerations of and apply, as does the discussion of the combiner and of the shared secret encoding in . Scloud+ has not been standardized and is still under evaluation . 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.

References Normative References 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 Standards for Efficient Cryptography Group Version 2.0 Round 1 submission to the Next-generation Commercial Cryptographic Algorithms Program (NGCC) 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. 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. Informative References 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 document describes the specification for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol. 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. 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. Microsoft NXP Semiconductors Federal Office for Information Security University of Waterloo This internet draft specifies FrodoKEM, an IND-CCA2 secure Key Encapsulation Mechanism (KEM). About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-longa-cfrg-frodokem/. Source for this draft and an issue tracker can be found at github.com/dstebila/frodokem-internet-draft. IANA n.d. Institute of Commercial Cryptography Standards (ICCS) Security Standardisation Research (SSR 2024), LNCS 15559, pp. 147-174, Springer

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 .

Acknowledgments This document follows the structure of and .