simon@josefsson.org

int Internet-Draft This document specify a hybrid key exchange method in the Secure Shell (SSH) protocol based on FrodoKEM (FrodoKEM-976) and X25519 with SHA-512 using Chempat as the combiner. Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Secure Shell (SSH) is a secure remote login protocol. The key exchange protocol described in supports an extensible set of methods. defines how elliptic curves are integrated into this extensible SSH framework, and specify "curve25519-sha256" to support the pre-quantum elliptic-curve Diffie-Hellman X25519 function . In it is described how the post-quantum lattice-based Streamlined NTRU Prime is combined with X25519 for SSH, and we base our protocol and document on it but replace sntrup761 with FrodoKEM-976 and use Chempat for the combiner. FrodoKEM provides a Key Encapsulation Method (KEM) based on learning with errors problem, designed to be safe even against quantum computers. The variant "FrodoKEM-976" offers a balance between security, performance and output sizes. To hedge against attacks on either of FrodoKEM-976 or X25519 a hybrid construction Chempat is used, with the intention that the hybrid would be secure if either of the involved algorithms are flawed. This document specify how to implement key exchange based on a Chempat hybrid between FrodoKEM-976 and X25519 in SSH. The SHA-512 in the name of this method refers to the HASH used in Section Output from Key Exchange of , not that of the hybrid KEM combiner.

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.

Key Exchange Method: frodokem976x25519-sha512 The key-agreement is done by the X25519 Diffie-Hellman protocol as described in Section Key Exchange Methods of , and the FrodoKEM-976 key encapsulation method described in . The key exchange procedure reuse the Elliptic Curve Diffie-Hellman (ECDH) key exchange defined in Sections ECDH Key Exchange and ECDH Message Numbers of . The protocol flow and the SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY messages are identical, except that we use different ephemeral public values Q_C and Q_S and shared secret K as described below. The SSH_MSG_KEX_ECDH_INIT value Q_C that holds the client's ephemeral public key MUST be constructed by concatenating the 15.632 byte public key output from the key generator of FrodoKEM-976 with the 32 byte K_A = X25519(a, 9) as described in and . The Q_C value is thus 15.664 bytes. The SSH_MSG_KEX_ECDH_REPLY value Q_S that holds the server's ephemeral public key MUST be constructed by concatenating the 15.792 byte ciphertext output from the key encapsulation mechanism of FrodoKEM-976 with the 32 byte K_B = X25519(b, 9) as described in and . The Q_S value is thus 15.824 bytes. Clients and servers MUST abort if the length of the received public keys Q_C or Q_S are not the expected lengths. An abort for these purposes is defined as a disconnect (SSH_MSG_DISCONNECT) of the session and SHOULD use the SSH_DISCONNECT_KEY_EXCHANGE_FAILED reason for the message, see Section Disconnection Message of . No further validation is required beyond what is described in , and . The SSH_MSG_KEX_ECDH_REPLY signature value is computed as described in with the following changes. Instead of encoding the shared secret K as 'mpint', it MUST be encoded as 'string'. The shared secret K value MUST be the 32-byte output octet string computed by Chempat-X25519-FrodoKEM-976 .

Acknowledgments The protocol and document is based on and .

Security Considerations The security considerations of , , , , and are inherited. FrodoKEM is designed for IND-CCA2 security even against quantum computers. Chempat is a conservatively designed way to combine a classical and post-quantum method. However new cryptographic primitives should be introduced and trusted conservatively, and new research findings may be published at any time that may warrant implementation reconsiderations. The increase in communication size and computational requirements may be a concern for limited computational devices, which would then not be able to take advantage of the improved security properties offered by this work. As discussed in the security considerations of Curve25519-sha256 , the X25519 shared secret K is used bignum-encoded in that document, and this raise a potential for a hash-processing time side-channel that could leak one bit of the secret due to different length of the bignum sign pad. This document resolve that problem by using string-encoding instead of bignum-encoding.

IANA Considerations IANA is requested to add a new "Method Name" of "frodokem976x25519-sha512" to the "Key Exchange Method Names" registry for Secure Shell (SSH) Protocol Parameters with a "reference" field to this RFC and the "OK to implement" field of "MUST".

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] This document describes the specification for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol. 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. Federal Information Processing Standard, FIPS 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. Microsoft NXP Semiconductors Federal Office for Information Security (BSI) 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. 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. This document specify a hybrid key exchange method in the Secure Shell (SSH) protocol based on Classic McEliece (mceliece6688128) and X25519 with SHA-512 using Chempat as the combiner. 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-josefsson-ssh-mceliece/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-ssh-mceliece. OpenSSH TinySSH This document describe 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. IANA