simon@josefsson.org

IETF Secure Shell Maintenance Ed25519 EdDSA ML-DSA post quantum pq signature ssh secsh This document describes the use of Ed25519 with ML-DSA-65 as a hybrid digital signature in the Secure Shell (SSH) protocol. Status information for this document may be found at . Discussion of this document takes place on the SSHM Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Secure Shell (SSH) is a secure remote-login protocol. It provides for an extensible variety of public key algorithms for identifying servers and users to one another. Ed25519 is a digital signature system. CRYSTALS-Kyber is a post-quantum digital signature system, standardized in as Module-Lattice-Based Digital Signature Standard (ML-DSA). This document specify how Ed25519 and ML-DSA-65 may be used in SSH, using the hybrid signature scheme suggested in .

Conventions Used In This Document The descriptions of key and signature formats use the notation introduced in , Section 3, and the string data type from , Section 5. Identifiers and terminology from and are used throughout the document.

Requirements Language 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.

Public Key Algorithm This document describes a public key algorithm for use with SSH, as per , Section 6.6. The name of the algorithm is "ssh-ed25519-ml-dsa-65". This algorithm only supports signing and not encryption. Standard implementations of SSH SHOULD implement this signature algorithm.

Public Key Format The "ssh-ed25519-ml-dsa-65" key format has the following encoding:

The content of 'key' is the concatenation of the Ed25519 32-octet public key described in , Section 5.1.5, with the 1952-octet public key described in , for the ML-DSA-65 algorithm. The resulting key length is therefor 1984.

Signature Algorithm Signatures are generated according to the following procedure, based on .

The 'hybridpk' value is the public key from the previous section. Here the fresh randomness MUST be 16 bytes, and only to be used for the signature. The 'hybridsigname' field is "Ed25519MLDSA65", and 'appname' is 'SSH' with 'appcontext' being 'SSH-Ed25519MLDSA65". Strings are encoded using ASCII . The signed message (s2,s1,r,h,m) is the concatenation of each value. The ML-DSA-65 signature 's2' is 3309 octets, the Ed25519 signature 's1' is 64 octets, 'r' is 16 octets, 'h' is 32 octets, therefor the signature size is 3421 octets plus the message itself. This protocol always uses the 'pure' version of ML-DSA (where ML-DSA signs the message), and not the 'prehashed' variant (where ML-DSA signs a previously hashed message). The ML-DSA 'context' input MUST be the string "ML-DSA-65-Ed25519-SSH" encoded in ASCII . ML-DSA may be used in deterministic or hedged mode.

Signature Format The "ssh-ed25519-ml-dsa-65" key format has the following encoding:

The 'signature' value is the signed message produced in accordance with the previous section.

Verification Algorithm Verification is done by invoking the verify functions for Ed25519 and ML-DSA-65 using the received values as follows, and taking the logical AND of their verification outputs.

SSHFP DNS Resource Records Usage and generation of the SSHFP DNS resource record is described in . This section illustrates the generation of SSHFP resource records for Ed25519MLDSA65 keys, and this document also specifies the corresponding code point to "SSHFP RR Types for public key algorithms" in the "DNS SSHFP Resource Record Parameters" IANA registry . The encoding of Ed25519MLDSA65 public keys is described in earlier sections. The SSHFP Resource Record for the Ed25519MLDSA65 public key with SHA-256 fingerprint would, for example, be:

Replace TBD1 with the value eventually allocated by IANA.

IANA Considerations This document augments the Public Key Algorithm Names in , Section 4.11.3. IANA is requested to add the following entry to "Public Key Algorithm Names" in the "Secure Shell (SSH) Protocol Parameters" registry : Public Key Algorithm Name Reference ssh-ed25519-ml-dsa-65 THIS-RFC IANA is requested to add the following entry to "SSHFP RR Types for public key algorithms" in the "DNS SSHFP Resource Record Parameters" registry : Value Description Reference TBD1 SSH-ED25519-ML-DSA-65 THIS-RFC

Security Considerations The security considerations in , Section 9 apply to all SSH implementations, including those using Ed25519MLDSA65. The security considerations in and apply to all uses of Ed25519 and ML-DSA-65, respectively, including those in SSH. Verification of the hybrid signature may leak timing information that can be used to infer which of the Ed25519 or ML-DSA-65 verifications failed, if an implementation avoid to invoke one verification when the other one fails. Ed25519MLDSA65 signatures are intended to be secure if SHA3-256 is secure and at least one of Ed25519 or ML-DSA-65 is secure. Cryptographic algorithms and parameters are usually broken or weakened over time. Implementers and users need to continously re-evaluate that cryptographic algorithms continue to provide the expected level of security.

Acknowledgments The text of was used as a template for this document.

Test vectors The following illustrate test vectors using file formats used by, for example, OpenSSH.

Private Key Private key:

Public-Key Public key:

Message The namespace context string used is "my-namespace", and the message is (including final newline):

Signature Signature:

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] 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 a method of verifying Secure Shell (SSH) host keys using Domain Name System Security (DNSSEC). The document defines a new DNS resource record that contains a standard SSH key fingerprint. [STANDARDS-TRACK] This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. National Institute of Standards and Technology

US Gaithersburg

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. IANA IANA This document describes the use of the Ed25519 and Ed448 digital signature algorithms in the Secure Shell (SSH) protocol. Accordingly, this RFC updates RFC 4253.