Composite Signatures: Are They Worth It?

draft-ietf-lamps-pq-composite-sigs, the draft specification for composite signatures, is in the final stages of standardization at the IETF. A composite signature combines ML-DSA with a traditional signature algorithm such as RSA or ECDSA. The two are presented as a single public key, a single signature, and a single algorithm identifier. A verifier accepts the composite only if both component signatures verify.

The benefit to this approach is clear: if one component breaks, the other still provides security. But composite signatures are not a drop-in upgrade into existing infrastructure, and they are not a way to keep legacy clients working. This post covers the benefit, dispels a few misconceptions, and outlines the trade-offs, which are significant.

The benefit: your security drops to the security of the traditional algorithm, not zero

Unlike traditional algorithms such as RSA and ECDSA, ML-DSA is a new algorithm standardized in August 2024. New algorithms carry two kinds of risk. The first is that the underlying “hard problem” turns out to be easier to solve than believed. The second is that a specific implementation has a bug, even if the math is sound.

Even though it is relatively new, ML-DSA has been scrutinized by cryptographers worldwide for almost a decade, so it is unlikely that there is a mathematical weakness. However, the second risk is not hypothetical. Implementation flaws have already been found in both ML-DSA and its sibling ML-KEM, which is also new and closely related mathematically to ML-DSA.

For ML-KEM, the KyberSlash attacks exploited secret-dependent timings in several implementations, including the official reference code. Secret keys were recovered within minutes in one variant and within a few hours in the other. A separate flaw, Clangover, arose when the Clang compiler turned constant-time source code into variable-time machine code.

For ML-DSA, a timing side-channel was found in the signing routine of the RustCrypto project’s ML-DSA implementation. Additionally, researchers have demonstrated power-analysis and fault-injection attacks that recover ML-DSA signing keys from hardware implementations of the algorithm.

In all of the cases above, the mathematical underpinning was sound, but implementation flaws leaked the keys. If you sign with ML-DSA alone and a flaw like one of the above is found, your security drops to zero until every affected implementation is patched and every key is rotated. If you sign with a composite, a break in the ML-DSA component leaves you with the security of the traditional component. And likewise, when RSA and ECDSA eventually fall to a quantum computer, composite signatures remain unforgeable thanks to ML-DSA.

With this in mind, composite signatures sound compelling. Before weighing the trade-offs against standalone ML-DSA, it is worth clearing up two misconceptions that can make composite look like an easier deployment than it is.

Misconception: composite is a backwards compatibility mechanism

Some may mistakenly think that composite is a compatibility mechanism that lets legacy clients keep working through a migration by using only the traditional algorithm. However, composite does not work that way.

A composite signature operates in a strict “AND” mode. In other words, both components of the signature must verify successfully for the signature to be trusted. There is no “OR” mode where an old client validates just the RSA half and ignores the part it does not understand. The draft is explicit that these composites do not provide backwards compatibility, and that only upgraded systems will understand the new algorithm identifiers.

In practice, this means a full migration. You need new certification authorities (CAs) with new composite key material. You need to update every server and every client so they understand the composite algorithm identifiers. A client that has not been upgraded does not fall back gracefully. Instead, the legacy client fails, because it sees an algorithm that it does not recognize.

Composite gives you codebase migration flexibility, not client migration flexibility. You can layer an experimental ML-DSA implementation on top of your mature, certified RSA or ECDSA implementation and get value right away, as the draft describes in Section 9.1. But you cannot use composite to keep a fleet of old devices that cannot handle ML-DSA communicating while you transition. If legacy interoperability is your goal, then composite signatures are the wrong tool.

Misconception: you can reuse your existing keys as components

It is tempting to think that you can take an RSA key pair you already have, pair it with a fresh ML-DSA key, and call the resulting key a composite. The draft forbids this. Key generation says that you MUST produce fresh material for both components, and component keys MUST NOT be used on their own or inside any other composite.

Reusing a component key opens the door to stripping attacks and cross-protocol attacks. If the same RSA key is used both standalone and inside a composite, an attacker may be able to lift a component signature out of the composite and present it in a context where it should not be valid. Fresh keys for every composite avoid this issue.

With those misconceptions out of the way, here are the trade-offs of composite over standalone ML-DSA.

The private key encoding is opinionated and stricter than the individual algorithm specs

RFC 9881, which defines how ML-DSA keys are used in X.509, allows three private key encodings. You may store the 32-byte seed, or the expanded key, or both together in one structure. This flexibility exists because for several months after the initial publication of FIPS 204, it was unclear whether FIPS 204 allowed implementations to store only the seed (NIST later clarified that only storing the seed was allowed). As a result of this ambiguity, some early implementations may only support storing and loading the expanded form.

The composite draft deviates from RFC 9881 and removes that flexibility, mandating the seed-only format. The ML-DSA private key must be encoded as the 32-byte seed, and the signing routine then re-derives the expanded key from that seed.

This matters for hardware, as a hardware security module (HSM) that stores ML-DSA keys only in expanded form cannot produce the interoperable composite private key format. The draft itself notes that a module built on top of an implementation that does not support seeds will be unable to reconstruct a compliant seed-based private key. If your HSM was designed and certified around the expanded key, it may be unsuitable for interoperable composite private keys without a firmware change or even a switch to a new product.

The ML-DSA context string is used in a way some APIs do not expose

The composite construction does not call the ML-DSA signing routine with just the message. Instead, it also passes the composite algorithm’s label down into the ML-DSA primitive as the ML-DSA context string. This binds the ML-DSA signature to the specific composite algorithm, and it is part of what gives composite its non-separability property. If someone strips the ML-DSA signature out and tries to verify it as plain ML-DSA with an empty context, it fails.

However, some cryptographic APIs do not let the caller set the ML-DSA context. FIPS 204 defines the context parameter, but not every library or module exposes a way to specify it. If your ML-DSA implementation hardcodes the context to empty, you cannot produce a composite signature with it. This is another way an existing ML-DSA implementation can turn out to be unusable as a composite component. Other specifications, such as RFC 9881 (for X.509 certificates and CRLs), avoid this issue by mandating the use of the empty context string for signing.

When quantum computers arrive, the traditional half becomes dead weight

Suppose the day comes when a quantum computer can break RSA and ECDSA. On that day, the traditional component of your composite stops providing any security value.

Despite not providing any security, the traditional half is still in every key, certificate, and signature. The draft discusses this directly. A single composite certificate can end up holding a mixture of a deprecated algorithm and a current one, which complicates deprecation policy and can leave implementations of obsolete algorithms present and in use.

Retiring the traditional half means standing up yet another PKI, with new keys and a new migration, this time to standalone ML-DSA or to a different algorithm.

Some will argue that this dead weight is acceptable. The traditional signature is small compared to the ML-DSA one, and carrying it uses little bandwidth and storage. But that argument misses a broader engineering point: all code is attack surface. Code for an obsolete algorithm is code an attacker can exploit, and code your team must maintain, audit, and keep patched, long after it provides any security value. Removing obsolete cryptographic code is worth doing even when that code is not itself the weak point.

Let’s Encrypt provides a good illustration of the best practice to remove obsolete cryptography even in non-security relevant contexts. RFC 5280 describes computing the Subject Key Identifier as a SHA-1 hash of the public key. SKIs are merely an opaque identifier with no security value, so calculating SKIs was never a security-relevant use of SHA-1. Even so, Let’s Encrypt moved certificates to a SHA-256 based SKI. In a similar vein, RFC 9919, which I co-authored, deprecates the use of SHA-1 in the lightweight profile for OCSP in non-security contexts. These demonstrate the same logic that argues for eventually removing a dead traditional component.

Go or no-go on Composite?

Composite signatures deliver what they promise. If ML-DSA suffers a cryptographic break or a serious implementation flaw, your security falls back to a traditional algorithm instead of collapsing to nothing. The same holds true once a quantum computer arrives and the traditional component no longer provides security.

But, is that additional protection worth the cost? Your regulatory environment may make this decision for you, in which case there’s nothing to weigh. However, if you do have the ability to choose, then ask yourself these two questions:

First, how much do you trust ML-DSA for your use case? The whole case for composite rests on the traditional component covering you if ML-DSA breaks. If you are confident that ML-DSA is sound and that your implementation of it is free of the kind of flaws described above, then the fallback buys you little, and standalone ML-DSA is simpler. If you are not confident, a fallback earns its keep.

Second, how agile is your infrastructure? Up front, composite demands a full migration to new CAs and fresh key material, and its design decisions, such as seed-only private keys and a non-empty ML-DSA context string, will exclude some existing implementations and HSMs. And, once a quantum computer arrives and the traditional half becomes dead weight, retiring it means standing up yet another PKI and running another migration, this time to standalone ML-DSA. An organization that can stand up a PKI and turn over its key material readily can absorb both the initial deployment and the later cleanup. However, one that cannot should think hard before signing up for two migrations instead of one.

If you are not yet ready to trust ML-DSA on its own, and you control infrastructure that can meet the draft’s requirements and the second migration down the line, adopting composite is a sound choice. Adoption guards against an ML-DSA flaw and against the arrival of a quantum computer. However, if you are confident in ML-DSA, then the initial migration cost, the eventual dead-weight component, and the second migration needed to shed it likely outweigh the benefit. In that case, you are better served by deploying standalone ML-DSA and migrating only once.

• Pqc