Composite ML-DSA Signatures for SSH

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 26 October 2025.¶

Copyright Notice

Copyright (c) 2025 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.¶

Table of Contents

1. Introduction

The development of quantum computers has raised concern towards traditional asymmetric cryptographic algorithms. A Cryptographically Relevant Quantum Computer (CRQC) will break RSA and elliptic curve signature schemes. There is a need to migrate to quantum-resistant signature schemes.¶

Recently, NIST publised the ML-DSA [FIPS204] algorithm, which is a post-quantum signature scheme. However, when using relatively new cryptographic schemes, the lack of maturing time makes people worry. Many hybrid solutions are thus proposed, which combine a traditional algorithm with a post-quantum algorithm.¶

[FIPS204] defines both pure ML-DSA and pre-hash ML-DSA. This document only uses pure ML-DSA.¶

This document describes how to combine ML-DSA with the elliptic curve signature schemes ECDSA, Ed25519 and Ed448 for authentication in the SSH [RFC4251] protocol.¶

2. Conventions and Definitions

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

This document is consistent with the terminology for hybrid signatures defined in [I-D.draft-ietf-pquip-pqt-hybrid-terminology].¶

The key and signature formats follows the notation introduced in [RFC4251], Section 3, and the string data type format follows the notation from [RFC4251], Section 5.¶

3. Composite Algorithms

A composite algorithm has one post-quantum algorithm, and one traditional algorithm.¶

(pk_1, sk_1) <- ML-DSA.KeyGen()
(pk_2, sk_2) <- ECCSigAlg.KeyGen()

Composite Public Key <- pk_1 || pk_2
Composite Private Key <- sk_1 || sk_2

M' <- Prefix || Domain || 0 || M

sig_1 <- ML-DSA.Sign(sk_1, M', ctx=Domain)
sig_2 <- ECCSigAlgo.Sign(sk_2, M')

Composite Signature <- (sig_1, sig_2)

(pk_1, pk_2) <- pk
(sig_1, sig_2) <- sig

M' <- Prefix || Domain || 0 || M

if not ML-DSA.Verify(pk_1, M', ctx=Domain)
    output "Invalid signature"
if not ECCSigAlgo.Verify(pk_2, M')
    output "Invalid signature"
if all succeeded, then
    output "Valid signature"

4. Public Key Algorithm

This section gives the concrete composite signature algorithms and their component algorithms. Their usage within SSH follows Section 6.6 of [RFC4253].¶

The following table defines a list of algorithms associated with specific PQ/T combinations.¶

5. Public Key Format

The key format for all parameter sets defined in this document follows the encoding pattern from [RFC4253], Section 6.6.¶

string identifier¶

string key¶

The 'identifier' is the key format identifier given in Table 1.¶

The 'key' is the composite public key generated as defined in Section 3.1. It is the concatenation of the public keys of the component schemes.¶

For ML-DSA, the public keys are defined in [FIPS204].¶

For ECDSA with curves secp256r1 or secp384r1, the public keys are defined in [RFC5656], Section 3.1. The public key is encoded from an elliptic curve point into an octet string as defined in Section 2.3.3 of [SEC1]; point compression MAY be used.¶

For Ed25519 and Ed448, the public keys are defined in [RFC8709], Section 6.¶

The "ssh-mldsa44-es256" key format has the following encoding:¶

string ssh-mldsa44-es256¶

string key¶

Here, 'key' is the concatenation of the 1312-octet ML-DSA-44 public key and the ECDSA public key using the secp256r1 curve.¶

The "ssh-mldsa65-es256" key format has the following encoding:¶

string ssh-mldsa65-es256¶

string key¶

Here, 'key' is the concatenation of the 1952-octet ML-DSA-65 public key and the ECDSA public key using the secp256r1 curve.¶

The "ssh-mldsa87-es384" key format has the following encoding:¶

string ssh-mldsa87-es384¶

string key¶

Here, 'key' is the concatenation of the 2592-octet ML-DSA-87 public key and the ECDSA public key using the secp384r1 curve.¶

The "ssh-mldsa44-ed25519" key format has the following encoding:¶

string ssh-mldsa44-ed25519¶

string key¶

Here, 'key' is the concatenation of the 1312-octet ML-DSA-44 public key and the 32-octet Ed25519 public key.¶

The "ssh-mldsa65-ed25519" key format has the following encoding:¶

string ssh-mldsa65-ed25519¶

string key¶

Here, 'key' is the concatenation of the 1952-octet ML-DSA-65 public key and the 32-octet Ed25519 public key.¶

The "ssh-mldsa87-ed448" key format has the following encoding:¶

string ssh-mldsa87-ed448¶

string key¶

Here, 'key' is the concatenation of the 2592-octet ML-DSA-87 public key and the 57-octet Ed448 public key.¶

6. Signature Format

The signature format for all parameter sets defined in this document following the encoding pattern defined in Section 6.6 of [RFC4253].¶

string identifier¶

string signature¶

The 'identifier' is the key format identifier given in Section 4.¶

The 'signature' is the composite signature generated as defined in Section 3.1. It is the concatenation of the signatures of the component schemes.¶

For ML-DSA, the signatures are defined in [FIPS204].¶

For ECDSA with curves secp256r1 and secp384r1, the signatures and their encodings are defined in [RFC5656], Section 3.1.2.¶

For Ed25519 and Ed448, the signature are defined in [RFC8709], Section 6.¶

The "ssh-mldsa44-es256" key format has the following encoding:¶

string ssh-mldsa44-es256¶

string signature¶

Here, 'signature' is the concatenation of the 2420-octet ML-DSA-44 signature and the ECDSA signature using the secp256r1 curve.¶

The "ssh-mldsa65-es256" key format has the following encoding:¶

string ssh-mldsa65-es256¶

string signature¶

Here, 'signature' is the concatenation of the 3309-octet ML-DSA-65 signature and the ECDSA signature using the secp256r1 curve.¶

The "ssh-mldsa87-es384" key format has the following encoding:¶

string ssh-mldsa87-es384¶

string signature¶

Here, 'signature' is the concatenation of the 4627-octet ML-DSA-44 signature and the ECDSA signature using the secp384r1 curve.¶

The "ssh-mldsa44-ed25519" key format has the following encoding:¶

string ssh-mldsa44-ed25519¶

string signature¶

Here, 'signature' is the concatenation of the 2420-octet ML-DSA-44 signature and the 64-octet Ed25519 signature.¶

The "ssh-mldsa65-ed25519" key format has the following encoding:¶

string ssh-mldsa65-ed25519¶

string signature¶

Here, 'signature' is the concatenation of the 3309-octet ML-DSA-44 signature and the 64-octet Ed25519 signature.¶

The "ssh-mldsa87-ed448" key format has the following encoding:¶

string ssh-mldsa87-ed448¶

string signature¶

Here, 'signature' is the concatenation of the 4627-octet ML-DSA-44 signature and the 114-octet Ed448 signature.¶

7. Security Considerations

The Security Considerations section of [RFC4251] also applies to this document.¶

The user can refer to [FIPS204] for security issues related to the ML-DSA post-quantum component of the composite algorithm and to the Security Considerations sections of [RFC5656] and [RFC8709] for the traditional component.¶

For the specific security issues raising from the use of a hybrid composite signature scheme, the user can refer to [I-D.draft-ietf-pquip-hybrid-signature-spectrums].¶

8. IANA Considerations

IANA is requested to add the following entries to "Public Key Algorithm Names" in the "Secure Shell (SSH) Protocol Parameters" registry [IANA.SSH]:¶

9. References

Acknowledgments

TODO acknowledge.¶

Authors' Addresses