Hybrid Digital Signatures with Strong Unforgeability

Introduction With the emergence of post-quantum (PQ) digital signatures, several groups (including ETSI CYBER and IETF LAMPS, TLS JOSE, SSHM) have explored hybrid constructions combining traditional and PQ algorithms. The main goal is to ensure long-term security during the transition to post-quantum cryptography, acknowledging that traditional algorithms are more mature than post-quantum ones and that the latter still raise uncertainty about their security. Current composite hybrid schemes typically provide existential unforgeability under chosen-message attacks (EUF-CMA), but do not ensure strong unforgeability. SUF-CMA extends EUF-CMA by requiring that it be computationally infeasible to produce a new valid signature even for a message-signature pair previously observed. This distinction has practical implications in preventing message replay, transaction duplication, and log poisoning. Although several recent algorithms such as EdDSA, ML-DSA, and SLH-DSA claim to achieve SUF-CMA security, some popular traditional schemes (RSA, ECDSA) only achieve EUF-CMA. Therefore, constructing a hybrid digital signature scheme maintaining SUF-CMA when one component does not is of particular interest. To address this concern, this document specifies a generic hybrid construction that guarantees SUF-CMA security when the second underlying component (e.g. the PQ scheme) is SUF-CMA. The construction is quite simple and can be applied generically across PQ/T signature combinations. It is originally proposed in , though its SUF-CMA security is not analyzed in the article.The construction could also be used for a hybrid PQ/PQ security, relying on two post-quantum components.

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 when, and only when, they appear in all capitals, as shown here. This document follows the terminology for post-quantum hybrid schemes defined in . This section recalls some of this terminology, but also adds other definitions used throughout the whole document: EUF-CMA: Existential Unforgeability under Chosen Message Attack. SUF-CMA: Strong Unforgeability under Chosen Message Attack. Post-Quantum Asymmetric Cryptographic Algorithm: An asymmetric cryptographic algorithm that is intended to be secure against attacks using quantum computers as well as classical computers. They can also be called quantum-resistant or quantum-safe algorithms. PQ/T Hybrid Digital Signature: A multi-algorithm digital signature scheme made up of two or more component digital signature algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm. Post-Quantum Traditional (PQ/T) Hybrid Composite Scheme: A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm and the resulting composite scheme is exposed as a singular interface of the same type as the component algorithms. Component Scheme: Each cryptographic scheme that makes up a PQ/T hybrid scheme or PQ/T hybrid protocol.

Proposed Construction The proposed construction ensures that the second (nested) signature binds the first (nested) signature, making the overall scheme SUF-CMA as long as the (typically PQ) component is SUF-CMA secure. The hybrid signature construction is defined in the following subsections. Before signing a message m, the hybrid scheme derives a message representative m' from m to address specific security concerns, and in particular to achieve non-separability, following a similar approach to .

Hybrid Key Generation

Hybrid Sign The Hybrid.Sign algorithm consists in signing a message m' derived from m with the first component, and then signing the concatenation m' || s1 of the derived message with the first signature with the second component. In the computation of the message representative: - Prefix is the byte encoding of the string "SUFHybridSignature2025", which in hexadecimal is "5355464879627269645369676E617475726532303235". - Label: a label which is specific to the particular component algorithms being used. - len(ctx): a single byte representing the length of ctx. - ctx: the context bytes. - PH(m): the hash of the message to be signed.

Hybrid Verify

Related works The hybrid construction in only provides SUF-CMA security if both components is providing SUF-CMA security and one of the components are deterministic. As traditional signatures do not provide any security against quantum attackers, when is used for PQ/T hybrid scheme, it does not provide SUF-CMA security against quantum attackers. In this document, only the second component needs to be SUF-CMA so that the hybrid scheme achieves SUF-CMA security. In contrast to , the signing process of the hybrid construction proposed in this document cannot be parallelized. Indeed, computing the hybrid signature s = (s1 || s2) requires to compute s1 = Sign_1(sk1, m') first in order to compute s2 = Sign_2(sk2, m' || s1).

Non-black-box Construction The proposed construction of this section ensures that the overall scheme is SUF-CMA as long as only one component is SUF-CMA secure. The hybrid signature construction is defined in the following subsections. The hybrid can be used for signature schemes that are built from the Fiat-Shamir paradigm as the first component and from any signature scheme as the second compoenent. Hence, they use a canonical identification scheme (ID) underlying a Fiat-Shamir construction and a signature scheme (Sig_2). This applies to combining EdDSA and any post-quantum signature scheme, for example ML-DSA. Before signing a message m, the hybrid scheme derives a message representative m' from m to address specific security concerns, and in particular to achieve non-separability, following a similar approach to .

Hybrid Key Generation

Hybrid Sign The Hybrid.Sign algorithm consists of applying the Fiat-Shamir paradigm for the first signature component. During the process (after the commitment has been computed), the second component is applied by signing the message and the commitment. The remainder of the Fiat-Shamir signature is computed using the second signature component instead of the message and the commitment as usual. In the computation of the message representative: - Prefix is the byte encoding of the string "SUFHybridSignature2025", which in hexadecimal is "5355464879627269645369676E617475726532303235". - Label: a specific label which is specific to the particular component algorithms being used. - len(ctx): a single byte representing the length of ctx. - ctx: the context bytes. - pk's: the concatenation of pk1 and pk2. - PH(m): the hash of the message to be signed.

Hybrid Verify

Security and Applicability The hybrid is SUF-CMA if one of the underlying signatures is SUF-CMA secure. Additionally, the ID scheme must have unique responses and the second signature component (post-quantum component) must fulfill message-bound security (MBS) and random-message validity (RMV) . The first requirement (on the traditional scheme) is fulfilled by EdDSA which is built from an ID scheme with unique responses. The second requirement (on the post-quantum scheme) is fulfilled by any of NIST standards/winners, i.e. ML-DSA, SLH-DSA, Falcon (to be FN-DSA).

Why the Binding Hybrid is Required Hybrid constructions are often intended to support requirements described in non-cryptographic terms as "single-signature semantics" or "artifact-level integrity." These terms generally refer to the operational goal where a message should be associated with one, and only one, valid signature string. In many real-world deployments, this security property is central: software releases, firmware images, signed logs, legal/financial documents, etc. In cryptography, this goal is most closely addressed by SUF-CMA security. While SUF-CMA does not mathematically guarantee uniqueness (the existence of only one valid signature per message), it provides a computational guarantee that an adversary cannot produce a different valid signature for a message that has already been signed. A binding hybrid is required because parallel hybrids fail to maintain SUF-CMA if one component (e.g., the traditional one) is only EUF-CMA or becomes forgeable. In such cases, the hybrid signature becomes malleable, allowing multiple valid signature strings for the same message, which breaks the intended "single-signature" logic of the application. A hybrid design achieves SUF-CMA only if one signature component is cryptographically bound to the other, forming a binding hybrid rather than signing the same message independently. Any successful forgery of a binding hybrid must fall into one of two categories:

New second signature on a new input:
The attacker generates a new traditional signature s1* that the legitimate signer never produced. The attacker would then need to forge a valid s2* over the concatenation m' || s1*. Producing such an s2* is a forgery against the PQC algorithm.
Different second-signature on an already-signed input:
The attacker reuses an existing (m', s1) but fabricates a distinct s2* for the same (m' || s1), yielding two valid second signatures for one message.

Both outcomes constitute a SUF-CMA forgery against the second component: the first case for a new message, the second for a second valid signature on an existing message. If the second component is SUF-CMA secure, neither case is computationally feasible, and the combined hybrid inherits SUF-CMA security.

Loss of Non-Repudiation in Parallel Hybrids under CRQC As described in , composite hybrids produce multiple component signatures independently over the same message.
Once a CRQC can forge the traditional component, an attacker can create an alternate classical signature s1* for a message that already has a valid hybrid signature (s1, s2). Because the PQC signature s2 remains valid independently of the classical signature, the modified pair (s1*, s2) also verifies successfully. While authenticity of the PQC component remains intact, the hybrid scheme is no longer SUF-CMA secure: multiple distinct hybrid signatures (s1, s2) and (s1*, s2) are both valid signatures for the same message. Therefore, once the classical algorithm becomes breakable, parallel hybrids no longer provide SUF-CMA security. On the contrary, this document’s hybrid construction, by binding the second signature s2 to the first signature s1, ensures single-signature semantics and preserves non-repudiation.

ECDSA vs EdDSA in Hybrid Constructions It is important to distinguish the properties of ECDSA and EdDSA. Indeed, even though both ECDSA (secp256r1/secp384r1) and EdDSA (Ed25519/Ed448) become mathematically breakable once a CRQC can derive private keys from public keys, their behaviour differs:

ECDSA is randomized and only provides EUF-CMA security.
EdDSA is designed to be SUF-CMA and its signing process is deterministic. In binding hybrids, EdDSA’s fixed, deterministic format enables unambiguous inclusion of s1 in the PQC input (m' || s1), simplifying verification and ensuring consistent interpretation across implementations.

Consequently, both algorithms lose their security properties, including SUF-CMA, once a CRQC can derive private keys. Therefore, neither algorithm can guarantee non-repudiation in a parallel hybrid construction under a quantum threat. The binding construction is therefore necessary regardless of the traditional algorithm used, as it ensures the overall SUF-CMA property is maintained by the post-quantum component.

Security Considerations

Security Model and Motivation The hybrid construction described in this document aims to guarantee strong unforgeability of the composite signature whenever the second component is SUF-CMA secure. This is in contrast to the composite construction in , where SUF-CMA of the composite generally requires both components to be SUF-CMA. The design proposed here strengthens that property: SUF-CMA of the overall construction depends only on the SUF-CMA of the second component, regardless of the security level of the first one.

SUF-CMA Security

Why SUF-CMA matters While EUF-CMA security could be sufficient in several use cases, weaknesses in EUF-only schemes allow "re-signing" the same message, enabling real-world exploits such as replay of messages, double receipts, and log poisoning. Moreover, many current deployed systems implicitly assume that all digital signatures are SUF-CMA secure. For this reason, the construction ensures that if the second component is SUF-CMA, the hybrid automatically resists replay and duplication attacks, aligning with best practices in recent signature standards (EdDSA, ML-DSA, SLH-DSA, etc.).

Security Rationale Intuitively, an adversary attempting to forge (m*, s1*, s2*) must either:

Forge s2* on (m* || s1*), which is infeasible if the second scheme is SUF-CMA;

Reuse an existing (m, s1) pair with a modified s2, which again breaks SUF-CMA of the second scheme.

Consequently, if the second component is SUF-CMA secure, the hybrid construction remains SUF-CMA secure even when the first component provides only EUF-CMA security. In contrast, if the second scheme were only EUF-CMA, the second attack (re-signing the same message differently) would no longer be excluded, and the hybrid construction would not be SUF-CMA secure. This contrasts with classical composite hybrids (e.g. trad(M) || PQ(M)) where the PQ signature does not authenticate the output of the traditional signature, leaving possible avenues for replay or signature substitution.

Non-Separability The document defines both notions of Weak Non-Separability (WNS) and Strong Non-Separability (SNS). The hybrid construction in this document achieves WNS because the Prefix of the message representative m' is an evidence that a verifier may be able to identify, preventing the validation of a component signature which would have been removed from the composite signature. However, SNS is not achieved, as s1 stripped from a composite signature s = (s1 || s2) is a valid component signature of the message m' and s2 is a valid component signature of the message m' || s1.

IANA Considerations This document has no IANA actions.