| Internet-Draft | SSH PQ Composite Signatures | August 2026 |
| Miller | Expires 21 February 2027 | [Page] |
This document specifies the integration of two composite post-quantum signature schemes into the Secure Shell (SSH) protocol. These schemes combine the post-quantum Module-Lattice Digital Signature Algorithm (ML-DSA) with Elliptic Curve signature algorithms (Ed25519 and ECDSA, respectively) 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 21 February 2027.¶
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 algorithms, it is desirable to use composite schemes that combine post-quantum and classical algorithms to protect against quantum attacks while ensuring the composite scheme remains at least as secure as the chosen classical algorithm alone, should a vulnerability be discovered in the post-quantum algorithm or its implementation.¶
This document specifies two composite signature schemes for SSH, mapping the COMPSIG-MLDSA44-Ed25519-SHA512 and COMPSIG-MLDSA87-ECDSA-P384-SHA512 schemes defined in [I-D.ietf-lamps-pq-composite-sigs] to the SSH protocol [RFC4253] using the SSH algorithm identifiers ssh-mldsa44-ed25519 and ssh-mldsa87-p384 respectively.¶
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.¶
For both the ssh-mldsa44-ed25519 and ssh-mldsa87-p384 algorithms, 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]. ML-DSA and Elliptic Curve keys are generated separately and the results from each are combined to form the composite key. Public key concatenation follows Section 4.1 of [I-D.ietf-lamps-pq-composite-sigs]. The private keys are also concatenated together, where the ML-DSA and EdDSA private keys are represented by their seeds, but the ECDSA private key is the private key integer. Private key concatenation follows Section 4.2 of [I-D.ietf-lamps-pq-composite-sigs].¶
ML-DSA key generation uses the ML-DSA.KeyGen_internal algorithm defined in [FIPS204] section 6.1 and not the ML-DSA.KeyGen algorithm, as only the former allows the private key seed to be emitted.¶
For the ssh-mldsa44-ed25519 algorithm, Ed25519 key generation is described in Section 5.1.5 of [RFC8032].¶
The public keys from the ML-DSA and Ed25519 key generation algorithms are combined by simple concatenation to form the composite public key. The composite public key consists of the raw ML-DSA-44 public key (1312 bytes) and the Ed25519 public key (32 bytes):¶
byte[1312] mldsa_pk
byte[32] ed25519_pk
¶
This 1344-byte combination is referred to as "composite_mldsa44_ed25519_public_key" henceforth in this document.¶
The composite private key is a concatenation of the private key seeds from the respective key generation algorithms. Each seed is 32 bytes:¶
byte[32] mldsa_seed
byte[32] ed25519_seed
¶
This 64-byte combination is referred to as "composite_mldsa44_ed25519_private_key" henceforth in this document.¶
For the ssh-mldsa87-p384 algorithm, ECDSA key generation is described in [FIPS.186-5] Appendix A.2 using the Curve P-384 domain parameters from [SP.800-186] section G.1.3.¶
The public keys from the ML-DSA and ECDSA key generation algorithms are combined by simple concatenation to form the composite public key. It consists of the raw ML-DSA-87 public key (2592 bytes) and the uncompressed ECDSA public key "Q":¶
byte[2592] mldsa_pk
string Q
¶
This combination is referred to as "composite_mldsa87_p384_public_key" henceforth in this document.¶
The composite private key is a concatenation of the ML-DSA seed (32 bytes) and the ECDSA private key "d".¶
byte[32] mldsa_seed
mpint d
¶
This combination is referred to as "composite_mldsa87_p384_private_key" henceforth in this document.¶
In the SSH protocol, both the "ssh-mldsa44-ed25519" and "ssh-mldsa87-p384" public key types share the following wire format:¶
string key_type_name
string composite_public_key
¶
Where "key_type_name" is either "ssh-mldsa44-ed25519" or "ssh-mldsa87-p384" and "composite_public_key" is the corresponding "composite_mldsa44_ed25519_public_key" (Section 4.1.1.1) or "composite_mldsa87_p384_public_key" (Section 4.1.2.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 key_type_name
string composite_public_key
string composite_private_key
¶
Where "key_type_name" is either "ssh-mldsa44-ed25519" or "ssh-mldsa87-p384".¶
The "composite_public_key" is the corresponding "composite_mldsa44_ed25519_public_key" (Section 4.1.1.1) or "composite_mldsa87_p384_public_key" (Section 4.1.2.1).¶
The "composite_private_key" is the corresponding "composite_mldsa44_ed25519_private_key" (Section 4.1.1.2) or "composite_mldsa87_p384_private_key" (Section 4.1.2.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.¶
The [I-D.ietf-lamps-pq-composite-sigs] composite signature scheme used here, like its underlying ML-DSA component, accepts a Context parameter that is used to domain separate signatures.¶
In all cases in the SSH protocol, this context value MUST be the empty string.¶
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 computes and combines the ML-DSA and Elliptic Curve signatures. Below, mldsa_sk, ed25519_sk, and ecdsa_sk are the private signing keys derived from or represented by mldsa_seed, ed25519_seed, and d, respectively.¶
This algorithm uses the ASCII string "COMPSIG-MLDSA44-Ed25519-SHA512" [43 4F 4D 50 53 49 47 2D 4D 4C 44 53 41 34 34 2D 45 64 32 35 35 31 39 2D 53 48 41 35 31 32] as the Label when creating the M' message to be signed.¶
The ML-DSA and Ed25519 signatures are calculated as:¶
The final composite signature is the concatenation of mldsa_sig and ed25519_sig in this order.¶
byte[2420] mldsa_sig
byte[64] ed25519_sig
¶
This 2484-byte combination is henceforth referred to as "composite_mldsa44_ed25519_signature".¶
This algorithm uses the ASCII string "COMPSIG-MLDSA87-ECDSA-P384-SHA512" [43 4F 4D 50 53 49 47 2D 4D 4C 44 53 41 38 37 2D 45 43 44 53 41 2D 50 33 38 34 2D 53 48 41 35 31 32] as the Label when creating the M' message to be signed.¶
The ML-DSA and ECDSA signatures are calculated as:¶
The final composite signature is the concatenation of mldsa_sig, r, and s in this order.¶
byte[4896] mldsa_sig
mpint r
mpint s
¶
This combination is henceforth referred to as "composite_mldsa87_p384_signature".¶
Signatures are represented in SSH using the following format:¶
string signature_type_name
string composite_signature
¶
Where "signature_type_name" is either "ssh-mldsa44-ed25519" or "ssh-mldsa87-p384" and "composite_signature" is the corresponding "composite_mldsa44_ed25519_signature" (Section 4.2.2.1) or "composite_mldsa87_p384_signature" (Section 4.2.2.2).¶
To verify a signature, the verifier reconstructs M' using the same process as defined for signature generation and verifies the ML-DSA and Elliptic Curve signatures.¶
Both ML-DSA and Elliptic Curve verification operations MUST return success for the composite signature to verify successfully. Failure of either verification operation MUST cause the composite signature verification to fail.¶
To verify an ssh-mldsa44-ed25519 signature, the verifier performs:¶
Both signatures must verify for the composite signature to verify.¶
To verify an ssh-mldsa87-p384 signature, the verifier performs:¶
Both signatures must verify for the composite signature to verify.¶
The security considerations of [I-D.ietf-lamps-pq-composite-sigs] apply here.¶
The security of this composite scheme depends on the security of both component algorithms. An adversary must forge both ML-DSA and Elliptic Curve signatures in order to forge a composite signature.¶
Implementations MUST NOT reuse component key material between composite and non-composite keys, or between multiple composite keys. See [I-D.ietf-lamps-pq-composite-sigs] section 9.3.¶
If neither of the component algorithms are broken, both ssh-mldsa44-ed25519 and ssh-mldsa87-p384 are Existentially Unforgeable under Chosen-Message Attack (EUF-CMA), since ML-DSA, Ed25519, and ECDSA are all EUF-CMA and SHA-512 is collision-resistant. This property will be degraded against particular adversary classes if either of of the constituent signature algorithms is broken. If ML-DSA is broken then the composite will not be EUF-CMA against quantum adversaries. Similarly, if the classical signature scheme is broken then the composite will not be EUF-CMA against classical adversaries. See [I-D.ietf-lamps-pq-composite-sigs] section 9.2.1.¶
This composite scheme is not Strongly Unforgeable under Chosen-Message Attack (SUF-CMA). Systems that rely on this property SHOULD NOT use this scheme.¶
This composite scheme provides Weak Non-Separability (WNS) for both components due to evidence of the composite in the Prefix in `M'`. See [I-D.ietf-lamps-pq-composite-sigs] section 9.2.3.¶
IANA is requested to register the algorithm names "ssh-mldsa44-ed25519" and "ssh-mldsa87-p384" in the "Public Key Algorithm Names" registry ([IANA-PUBKEYS]).¶
Cindy Lin offered valuable feedback on this document.¶