Secure Shell Key Exchange Method Using Chempat Hybrid of Classic McEliece and X25519 with SHA-512: mceliece6688128x25519-sha512

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 mceliece6688128 and use Chempat for the combiner. Classic McEliece provides a code-based Key Encapsulation Method (KEM) designed to be safe even against quantum computers. The variant "mceliece6688128" offers a balance between performance and output sizes. To hedge against attacks on either of mceliece6688128 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 Classic McEliece mceliece6688128 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: mceliece6688128x25519-sha512 The key-agreement is done by the X25519 Diffie-Hellman protocol as described in Section Key Exchange Methods of , and the mceliece6688128 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 1044992 byte public key output from the key generator of mceliece6688128 (or mceliece6688128f, see ) with the 32 byte K_A = X25519(a, 9) as described in and . The Q_C value is thus 1045024 bytes. The SSH_MSG_KEX_ECDH_REPLY value Q_S that holds the server's ephemeral public key MUST be constructed by concatenating the 208 byte ciphertext output from the key encapsulation mechanism of mceliece6688128 (or mceliece6688128f, see ) with the 32 byte K_B = X25519(b, 9) as described in and . The Q_S value is thus 240 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-mceliece6688128 .

mceliece6688128f The f and non-f versions are interoperable. The f versions have faster key generation, while the non-f versions have simpler key generation. For example, a key generated with mceliece6688128f can decapsulate ciphertexts that were encapsulated with mceliece6688128, and vice versa. The secret-key sizes (and formats) are the same, the encapsulation functions are the same, and the decapsulation functions are the same. Implementations of this protocol can chose between mceliece6688128 or mceliece6688128f, however the name of this protocol is "mceliece6688128x25519-sha512" even for implementations that use mceliece6688128f internally. Choosing mceliece6688128 generally reduce code size and complexity (at the expense of performance), and choosing mceliece6688128f generally improve performance (at the expense of code size and complexity).

Acknowledgments The protocol and document is based on . The authors would like to thank for discussion and suggesting the mceliece6688128 variant.

Implementation Status An earlier implementation of this protocol is available as a patch for OpenSSH , released under a BSD-style license.

Security Considerations The security considerations of , , , , and are inherited. Classic McEliece is a KEM designed for IND-CCA2 security at a very high security level, even against quantum computers. The algorithm has been studied by researchers for many years, and there are implementations in the public domain for a wide range of architectures. 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 "mceliece6688128x25519-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".