Mothma: Generic Instantiated PQ/T Hybrid Signatures

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 23 April 2026.¶

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

This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft.¶

Table of Contents

1. Introduction

To hedge against attacks on a traditional digital signature methods such as Ed25519 [RFC8032] or a post-quantum digital signature method such as SLH-DSA [NIST.FIPS.205], it is possible to combine both algorithms to define a combined method as a joint signature method. Using the terminology of [RFC9794], this combination forms a PQ/T Hybrid Digital Signature.¶

Mothma is a generic pattern to create a PQ/T Hybrid Digital Signature methods based on at least one post-quantum algorithm and at least one traditional algorithm. The idea is that Mothma can be analyzed generally and some assurance can be had that it behaves well. For ease of presentation, this document combine one traditional algorithm with one post-quantum algorithm.¶

While a naive approach would be to integrate a generic Mothma combiner into protocols and have the protocol and implementation negotiate parameters, that leads to complexity detrimental to security. Therefor this document describe specific instances of Mothma applied on selected algorithms.¶

Mothma is based on the hybrid signature scheme suggested in [DJB-HYBRID-SIGNATURE].¶

We initially suggest Mothma as combinations of traditional EdDSA, ECDSA and RSA methods with the post-quantum methods of ML-DSA, SLH-DSA, XMSS and LMS. Other combinations may be added following the same generic pattern, and may be proposed for addition to this document.¶

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

Mothma is defined as follows:¶

The signed message is (s2,s1,r,h,m) where

   m = the message being signed,
   r = H(fresh randomness chosen during signing),
   h = H(r,H(hybridpk),hybridsigname,appname,appcontext,m),
   s1 = traditional signature of (r,h),
   s2 = post-quantum signature of (s1,r,h),
   H = SHA3-256.

The hash function SHA3-256 is defined in [NIST.FIPS.202].¶

Using H(hybridpk) instead of hybridpk makes clear that H(hybridpk) can be saved alongside hybridpk, guaranteeing that the key is hashed only once when it's generated or received.¶

Here the fresh randomness MUST be 16 bytes, and only to be used for one signature.¶

The 'hybridsigname' value is specified by each instantiated variant, whereas the 'appname' and 'appcontext' will come from the application using Mothma. These are 0-255 octet long strings, and when text values are put into these fields the encoding is ASCII [RFC0020].¶

The signed message (s2,s1,r,h,m) is the concatenation of its values.¶

The signature SHOULD NOT be detached from its corresponding message 'm' because this leads to fragile implementation, although we recognize that Mothma variants MAY be integrated into existing legacy protocols this way.¶

Verification is done by confirming that the value of 'h' and invoking the verify functions for the traditional and post-quantum system using the received values as follows, and taking the logical AND of their verification outputs.¶

   Signed message is (s2,s1,r,h,m)
   h' = H(r,H(hybridpk),hybridsigname,appname,appcontext,m),
   v1 = Ed25519 verification of s1 on message (r,h),
   v2 = ML-DSA-65 verification of s2 on message (s1,r,h),
   verify = h == h' && v1 && v2

4. Naming

Protocols wishing to utilize PQ/T Hybrid Signatures described in this document MUST refer to one of the derived instantiated algorithm identifiers and MUST NOT adopt a generic facility where the individual algorithms are parameters.¶

The convention for identifiers is "Mothma-TSIG-PQSIG" replacing "TSIG" and "PQSIG" with a brief mnemonic identifying the traditional and post-quantum algorithm respectively.¶

5. EdDSA

EdDSA [RFC8032] is a digital signature system, with variants Ed25519 and Ed448. This protocol always uses the 'pure' version of EdDSA.¶

The Ed448 'context' input MUST be the Mothma name, e.g., "Mothma-Ed25519-ML-DSA-65".¶

6. ECDSA

ECDSA [NIST.FIPS.186] is a digital signature system, with variants for the P256, P384 and P521 curves, and the Brainpool curves [RFC5639] brainpoolP256r1, brainpoolP384r1, and brainpoolP512r1. This protocol always uses the 'pure' version of ECDSA.¶

7. RSA

RSA [RFC8017] is a digital signature system, with two variants RSASSA-PSS and RSASSA-PKCS1-v1_5. This document do not define any Mothma RSA variants, pending a decision on how to map its arbitrary public key and signature output sizes into Mothma's fixed-size approach, and pending interest from anyone who desire to use RSA for PQ/T hybrid signatures.¶

8. ML-DSA

CRYSTALS-Dilithium [PQ-CRYSTALS] is a post-quantum digital signature system, standardized in [NIST.FIPS.204] as Module-Lattice-Based Digital Signature Standard (ML-DSA).¶

This protocol always uses the 'pure' version of ML-DSA (where ML-DSA signs the message), and not the 'prehashed' variant (where ML-DSA signs a previously hashed message). ML-DSA may be used in deterministic or hedged mode.¶

The ML-DSA 'context' input MUST be the Mothma name, e.g., "Mothma-Ed25519-ML-DSA-65".¶

9. SLH-DSA

Sphincs+ [SPHINCS] is a stateless hash-based digital signature system, standardized in [NIST.FIPS.205] as Stateless Hash-Based Digital Signature Algorithm (SLH-DSA).¶

The SLH-DSA 'context' input MUST be the Mothma name, e.g., "Mothma-Ed25519-ML-DSA-65".¶

10. XMSS & LMS

XMSS [RFC8391] and LMS [RFC8554] are stateful hash-based digital signature systems, discussed in [NIST.SP.800-208] as Recommendation for Stateful Hash-Based Signature Schemes.¶

11. Mothma variants

12. Acknowledgments

The method was suggested by Daniel J. Bernstein. This document re-use ideas and some text from [CHEMPAT].¶

13. IANA Considerations

None.¶

14. Security Considerations

The security considerations of all references apply.¶

The intention is that Mothma hybrid signatures should be secure if at least one of the traditional and post-quantum algorithms is secure.¶

Cryptographic algorithms and parameters are usually broken or weakened over time. Implementers and users need to continously re-evaluate that cryptographic algorithms continue to provide the expected level of security.¶

Author's Address