| Internet-Draft | MLDSA65-Ed25519 SSH | April 2026 |
| Miller | Expires 30 October 2026 | [Page] |
This document specifies the integration of the MLDSA65-Ed25519-SHA512 composite signature scheme into the Secure Shell (SSH) protocol. This scheme combines the post-quantum Module-Lattice Digital Signature Algorithm (ML-DSA) with the classical elliptic curve Ed25519 signature algorithm to provide security against both quantum and classical adversaries.¶
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 30 October 2026.¶
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.¶
The Secure Shell (SSH) protocol [RFC4251] is a protocol for secure remote login and other secure network services over an untrusted network.¶
The expected arrival of quantum computing poses a threat to traditional asymmetric cryptography. Post-quantum algorithms such as ML-DSA [FIPS204] have been developed to remain secure against a quantum computer-equipped adversary. However, given the relative novelty of the post-quantum algoritms, it is desirable to use composite schemes that combine post-quantum and classical algorithms to protect against quantum attacks while promising to be "no worse" than the chosen classical algorithm should a vulnerability be discovered in the post-quantum algorithm or its implementation.¶
This document specifies a composite signature scheme for SSH, mapping the COMPSIG-MLDSA65-Ed25519-SHA512 scheme defined in [I-D.ietf-lamps-pq-composite-sigs] to the SSH protocol [RFC4253] using the identifier ssh-mldsa65-ed25519@openssh.com.¶
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.¶
All encoding data types ("byte", "string", etc.) are as specified in Section 5 of [RFC4251].¶
All length units are given in bytes unless otherwise specified.¶
The algorithm name for this composite signature scheme is "ssh-mldsa65-ed25519@openssh.com". The underlying key generation, signing and verification primitives are as specified in [I-D.ietf-lamps-pq-composite-sigs], but are also described briefly below.¶
Keys are generated using the process specified in Section 3.1 of [I-D.ietf-lamps-pq-composite-sigs]. Specifically, ML-DSA and Ed25519 keys are generated separately from seeds and the resultant public for each are combined to form the composite public key. Private keys are combined as seeds and not as expanded keys.¶
ML-DSA key generation uses the ML-DSA.KeyGen_internal algorithm as defined in [FIPS204] section 6.1 and not the usual ML-DSA.KeyGen algorithm as the latter emits an expanded private key and not the required seed.¶
Ed25519 key generation is described in Section 5.1.5 of [RFC8032].¶
Seeds to both ML-DSA and Ed25519 MUST be sourced from a cryptographically sound source, such as a CSPRNG/RBG.¶
The resultant public keys from the respective ML-DSA and Ed25519 key generation algorithms are combined by simple concatenation to form a composite public key. Specifically it consists of the raw ML-DSA-65 public key (1952 bytes) and the Ed25519 public key (32 bytes), for a total of 1984 bytes:¶
byte[1952] mldsa_pk
byte[32] ed25519_pk
¶
This 1984-byte combination is referred to as "composite_public_key" henceforth in this document.¶
The composite private key is also a concatenation, but its elements are the private key seeds for the respective algorithms. Each of these seeds is 32 bytes.¶
byte[32] mldsa_seed
byte[32] ed25519_seed
¶
This 64-byte combination is referred to as "composite_private_key" henceforth in this document.¶
The "ssh-mldsa65-ed25519@openssh.com" public key as it appears in the SSH protocol has the following format:¶
string "ssh-mldsa65-ed25519@openssh.com"
string composite_public_key
¶
Where "composite_public_key" is as described in Section 4.1.1.¶
When adding a key to an agent [I-D.ietf-sshm-ssh-agent] using the SSH_AGENTC_ADD_IDENTITY or SSH_AGENTC_ADD_ID_CONSTRAINED messages, the key data MUST have the following format:¶
string "ssh-mldsa65-ed25519@openssh.com"
string composite_public_key
string composite_private_key
¶
Where "composite_public_key" is as described in Section 4.1.1 and "composite_private_key" is as described in Section 4.1.2.¶
This private key serialisation may also be used as the basis of on-disk key formats, though these are beyond the scope of this document.¶
To sign a message M, the signer first constructs a message representative M' as follows:¶
M' = Prefix || Label || len(ctx) || ctx || SHA512(M)
¶
Where:¶
The signer then computes:¶
The final composite signature is the concatenation of mldsa_sig and ed25519_sig.¶
byte[3309] mldsa_sig
byte[64] ed25519_sig
¶
This 3373-byte combination is henceforth referred to as "composite_signature".¶
To verify a signature, the verifiere reconstructs M' using the same process as defined for generation. The signature is valid if and only if both underlying signature verifications succeed:¶
Signatures are represented in SSH using the following format:¶
string "ssh-mldsa65-ed25519@openssh.com"
string composite_signature
¶
Where "composite_signature" is as defined in Section 4.4.1.¶
The COMPSIG-MLDSA65-Ed25519-SHA512 signature algorithm, like its underlying ML-DSA component, accepts a Context parameter that may be used to enforce domain separation between signatues.¶
TODO TODO TODO In all cases in the SSH protocol, this context value is the empty string, but if we ever change our minds then this is where we'd describe what contexts are used for each signature/verification operation. TODO TODO TODO.¶
The security of this composite scheme depends on the strength of both component algorithms. An adversary must break both ML-DSA-65 and Ed25519 to forge a signature.¶
Implementations MUST NOT reuse component key material between composite and non-composite keys, or between multiple composite keys.¶