Post-Quantum Composite Signatures in SSH
draft-ietf-sshm-composite-sigs-00
| Document | Type | Active Internet-Draft (sshm WG) | |
|---|---|---|---|
| Author | Damien Miller | ||
| Last updated | 2026-08-22 | ||
| Replaces | draft-miller-sshm-composite-sigs | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
Mailing list discussion |
||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-sshm-composite-sigs-00
Secure Shell (SSHM) D. Miller
Internet-Draft OpenSSH
Intended status: Standards Track 21 August 2026
Expires: 22 February 2027
Post-Quantum Composite Signatures in SSH
draft-ietf-sshm-composite-sigs-00
Abstract
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.
Status of This Memo
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 22 February 2027.
Copyright Notice
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.
Miller Expires 22 February 2027 [Page 1]
Internet-Draft SSH PQ Composite Signatures August 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Algorithm specifications . . . . . . . . . . . . . . . . . . 3
4.1. Key generation . . . . . . . . . . . . . . . . . . . . . 3
4.1.1. ssh-mldsa44-ed25519 . . . . . . . . . . . . . . . . . 3
4.1.2. ssh-mldsa87-p384 . . . . . . . . . . . . . . . . . . 4
4.1.3. SSH Public Key Format . . . . . . . . . . . . . . . . 5
4.1.4. SSH Private Key Format . . . . . . . . . . . . . . . 5
4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Signature contexts . . . . . . . . . . . . . . . . . 6
4.2.2. Signature Generation . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
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.
Miller Expires 22 February 2027 [Page 2]
Internet-Draft SSH PQ Composite Signatures August 2026
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology
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.
4. Algorithm specifications
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.
4.1. Key generation
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.
4.1.1. ssh-mldsa44-ed25519
For the ssh-mldsa44-ed25519 algorithm, Ed25519 key generation is
described in Section 5.1.5 of [RFC8032].
Miller Expires 22 February 2027 [Page 3]
Internet-Draft SSH PQ Composite Signatures August 2026
4.1.1.1. Composite raw public key
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.
4.1.1.2. Composite raw private key
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.
4.1.2. ssh-mldsa87-p384
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.
4.1.2.1. Composite raw public key
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.
4.1.2.2. Composite raw private key
The composite private key is a concatenation of the ML-DSA seed (32
bytes) and the ECDSA private key "d".
Miller Expires 22 February 2027 [Page 4]
Internet-Draft SSH PQ Composite Signatures August 2026
byte[32] mldsa_seed
mpint d
This combination is referred to as
"composite_mldsa87_p384_private_key" henceforth in this document.
4.1.3. SSH Public Key Format
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).
4.1.4. SSH Private Key Format
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.
4.2. Signatures
Miller Expires 22 February 2027 [Page 5]
Internet-Draft SSH PQ Composite Signatures August 2026
4.2.1. Signature contexts
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.
4.2.2. Signature Generation
To sign a message M, the signer first constructs a message
representative M' as follows:
M' = Prefix || Label || len(ctx) || ctx || SHA512(M)
Where:
* Prefix: The ASCII string "CompositeAlgorithmSignatures2025" [43 6F
6D 70 6F 73 69 74 65 41 6C 67 6F 72 69 74 68 6D 53 69 67 6E 61 74
75 72 65 73 32 30 32 35].
* Label: The ASCII algorithm label specific to the signature
algorithm.
* len(ctx): A single unsigned byte representing the length of the
context string.
* ctx: The context string.
* SHA512(M): The SHA-512 hash of the original message M.
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.
4.2.2.1. ssh-mldsa44-ed25519
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:
* mldsa_sig = ML-DSA-44.Sign(mldsa_sk, M', ctx=Label)
Miller Expires 22 February 2027 [Page 6]
Internet-Draft SSH PQ Composite Signatures August 2026
* ed25519_sig = Ed25519.Sign(ed25519_sk, M')
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".
4.2.2.2. ssh-mldsa87-p384
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:
* mldsa_sig = ML-DSA-87.Sign(mldsa_sk, M', ctx=Label)
* r, s = ECDSA-P384.Sign(ecdsa_sk, M')
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".
4.2.2.3. SSH Signature Format
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).
Miller Expires 22 February 2027 [Page 7]
Internet-Draft SSH PQ Composite Signatures August 2026
4.2.2.4. Signature Verification
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.
4.2.2.4.1. ssh-mldsa44-ed25519
To verify an ssh-mldsa44-ed25519 signature, the verifier performs:
* ML-DSA-44.Verify(mldsa_pk, M', mldsa_sig, ctx=Label)
* Ed25519.Verify(ed25519_pk, M', ed25519_sig)
Both signatures must verify for the composite signature to verify.
4.2.2.4.2. ssh-mldsa87-p384
To verify an ssh-mldsa87-p384 signature, the verifier performs:
* ML-DSA-87.Verify(mldsa_pk, M', mldsa_sig, ctx=Label)
* ECDSA-P384.Verify(Q, M', r, s)
Both signatures must verify for the composite signature to verify.
5. Security Considerations
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
Miller Expires 22 February 2027 [Page 8]
Internet-Draft SSH PQ Composite Signatures August 2026
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.
6. IANA Considerations
IANA is requested to register the algorithm names "ssh-
mldsa44-ed25519" and "ssh-mldsa87-p384" in the "Public Key Algorithm
Names" registry ([IANA-PUBKEYS]).
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Miller Expires 22 February 2027 [Page 9]
Internet-Draft SSH PQ Composite Signatures August 2026
[I-D.ietf-lamps-pq-composite-sigs]
Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S.
Fluhrer, "Composite Module-Lattice-Based Digital Signature
Algorithm (ML-DSA) for use in X.509 Public Key
Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-lamps-pq-composite-sigs-19, 21 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-19>.
[FIPS204] "Module-lattice-based digital signature standard",
National Institute of Standards and Technology (U.S.),
FIPS 204, DOI 10.6028/nist.fips.204, August 2024,
<https://doi.org/10.6028/nist.fips.204>.
[FIPS.186-5]
National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS PUB 186-5,
DOI 10.6028/NIST.FIPS.186-5, February 2023,
<https://doi.org/10.6028/NIST.FIPS.186-5>.
[SP.800-186]
National Institute of Standards and Technology,
"Recommendations for Discrete Logarithm-based
Cryptography: Elliptic Curve Domain Parameters", SP
800-186, DOI 10.6028/NIST.SP.800-186, February 2023,
<https://doi.org/10.6028/NIST.SP.800-186>.
7.2. Informative References
[I-D.ietf-sshm-ssh-agent]
Miller, D., "SSH Agent Protocol", Work in Progress,
Internet-Draft, draft-ietf-sshm-ssh-agent-15, 28 December
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
sshm-ssh-agent-15>.
[IANA-PUBKEYS]
IANA, "Public Key Algorithm Names",
<https://www.iana.org/assignments/ssh-parameters/>.
Acknowledgements
Cindy Lin offered valuable feedback on this document.
Author's Address
Damien Miller
OpenSSH
Email: djm@openssh.com
Miller Expires 22 February 2027 [Page 10]
Internet-Draft SSH PQ Composite Signatures August 2026
URI: https://www.openssh.com/
Miller Expires 22 February 2027 [Page 11]