Internet-Draft SSH PQ Composite Signatures July 2026
Miller Expires 24 January 2027 [Page]
Workgroup:
Secure Shell (SSHM)
Internet-Draft:
draft-miller-sshm-composite-sigs-00
Published:
Intended Status:
Standards Track
Expires:
Author:
D. Miller
OpenSSH

Post-Quantum Composite Signatures in SSH

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 24 January 2027.

Table of Contents

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.

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]. Specifically, ML-DSA and Elliptic Curve keys are generated separately and the resultant public keys from each are combined to form the composite public key. ML-DSA private keys are always represented in wire formats 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.

4.1.1. ssh-mldsa44-ed25519

For the ssh-mldsa44-ed25519 algorithm, Ed25519 key generation is described in Section 5.1.5 of [RFC8032]. Ed25519 private keys are also represented as seeds in wire formats.

4.1.1.1. Composite raw public key

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-44 public key (1312 bytes) and the Ed25519 public key (32 bytes), for a total of 1344 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 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_mldsa44_ed25519_private_key" henceforth in this document.

4.1.2. ssh-mldsa87-p384

For ssh-mldsa87-p384, ECDSA key generation is specified in Appendix A.2 of [FIPS.186-5] using the Curve P-384 domain parameters specified in section G.1.3 of [SP.800-186].

4.1.2.1. Composite raw public key

The resultant public keys from the respective ML-DSA and ECDSA key generation algorithms are combined to form a composite public key. Specifically, it consists of the raw ML-DSA-87 public key (2592 bytes) and the 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 similarly constructed from the ML-DSA seed alongside 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.

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

4.2.1. Signature contexts

The [I-D.ietf-lamps-pq-composite-sigs] composite signature scheme, like its underlying ML-DSA component, accepts a Context parameter that may be used to enforce domain separation between signatures.

In all cases in the SSH protocol, this context value is 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 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 then computes and combines the ML-DSA and Elliptic Curve signatures as described in the following sections. In the algorithm invocations below, mldsa_sk, ed25519_sk, and ecdsa_sk denote 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 then calculated as:

  • mldsa_sig = ML-DSA-44.Sign(mldsa_sk, M', ctx=Label)
  • ed25519_sig = Ed25519.Sign(ed25519_sk, M')

The final composite signature is the concatenation of mldsa_sig and ed25519_sig.

    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 then 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.

    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).

4.2.2.4. Signature Verification

To verify a signature, the verifier reconstructs M' using the same process as defined for signature generation. The verifier then verifies the ML-DSA and Elliptic Curve signatures as described in the following sections.

Both verification operations MUST return success for the composite signature to verify successfully. Failure of either the ML-DSA or Elliptic Curve verification MUST cause the verification of the composite signature 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)

The verifier then checks both results as described above.

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)

The verifier then checks both results as described above.

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 strength of both component algorithms. An adversary must break both ML-DSA and the Elliptic Curve algorithm to forge a signature.

Implementations MUST NOT reuse component key material between composite and non-composite keys, or between multiple composite keys.

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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8174>.
[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, , <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, , <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, , <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, , <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, , <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/>.

Author's Address

Damien Miller
OpenSSH