RFC 9955

Hybrid Signature Spectrums

📅 published July 2026, from ietf

RFC 9955 💖 Hybrid Signature Spectrums

Who wrote it: N. Bindel (SandboxAQ), B. Hale (Naval Postgraduate School), D. Connolly (SandboxAQ), and F. Driscoll (UK National Cyber Security Centre) 👑
Category: Informational, so it's published for info and isn't a standards track spec 📚
Date: July 2026 📅
ISSN: 2070-1721
Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🙈

Abstract ✨

okay so this doc is all about classifying design goals and security considerations for hybrid digital signature schemes 🦋 It covers proof composability, non-separability of the component signatures given a hybrid signature, backwards and forwards compatibility, hybrid generality, and Simultaneous Verification (SV). it's giving a whole spectrum of trade-offs, bestie 💅

Status of This Memo 📜

this document is not an Internet Standards Track specification. it's published for informational purposes, so no pressure 🌸

it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious 🤓

for the current status, errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9955 🔗

Copyright Notice ©️

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. please read these carefully, because they spell out your rights and restrictions for this doc 🙏

Code Components extracted from this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. they're provided without warranty, as described in the Revised BSD License ⚖️

Table of Contents 🗺️

1.  Introduction
  1.1.  Terminology
  1.2.  Motivation for Use of Hybrid Signature Schemes
    1.2.1.  Complexity
    1.2.2.  Time
  1.3.  Goals
    1.3.1.  Hybrid Authentication
    1.3.2.  Proof Composability
    1.3.3.  Weak Non-Separability
    1.3.4.  Strong Non-Separability
    1.3.5.  Backwards and Forwards Compatibility
    1.3.6.  Simultaneous Verification
    1.3.7.  Hybrid Generality
    1.3.8.  High Performance
    1.3.9.  High Space Efficiency
    1.3.10. Minimal Duplicate Information
2.  Non-Separability Spectrum
3.  Artifacts
  3.1.  Artifacts vs. Separability
  3.2.  Artifact Locations
  3.3.  Artifact Location Comparison Example
4.  Need for Approval Spectrum
5.  EUF-CMA Challenges
6.  Discussion of Advantages and Disadvantages
  6.1.  Backwards Compatibility vs. SNS
  6.2.  Backwards Compatibility vs. Hybrid Unforgeability
  6.3.  Simultaneous Verification vs. Low Need for Approval
7.  Security Considerations
8.  IANA Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🦋

so, plans to move protocols to post-quantum cryptography tend to focus on confidentiality, mostly because of store and decrypt attacks 😬 The idea is that data encrypted today with traditional algorithms could get decrypted later by an attacker who has a sufficiently powerful quantum computer, also known as a Cryptographically Relevant Quantum Computer (CRQC).

it's also important to think about moving authentication to post-quantum, because waiting creates risks 🫶 For example, attackers may be able to carry out quantum attacks against RSA-2048 [RSA] years before the public knows those capabilities exist. some applications are also really hard or slow to switch algorithms on. root certificates, for instance, are often valid for about 20 years or longer 🕰️ And there are applications where checking past authenticity later on matters, like long-lived digital signatures on legal documents 📄

that said, there have been successful attacks on post-quantum algorithms and on implementations of them too 💀 Sometimes the attack exploits implementation issues, like [KYBERSLASH], which exploits timing variations, or [HQC_CVE], which exploits implementation bugs. other times an attack works against every implementation of the specified algorithm. research says implementation-independent attacks published in 2023 or earlier broke 48% of the proposals in Round 1 of the NIST Post-Quantum Cryptography Standardization Project, 25% of the proposals not broken by the end of Round 1, and 36% of the proposals NIST selected for Round 2 [QRCSP]. yikes 😭

that's one reason people consider 'hybrid' cryptographic algorithms, which combine traditional and post-quantum algorithms (or, more generally, a combination of two or more algorithms) ✨ The main goal of hybrid algorithms is to guard against quantum computers while making it clear the change isn't reducing security. the security premise is that if at least one of the two component algorithms in the hybrid scheme holds, the confidentiality or authenticity the scheme offers is maintained 🛡️ Also, the word 'hybrid' gets used a lot, but this document only uses it in this algorithm sense, so no mixing it up 🙅‍♀️

whether hybridization is wanted depends on the use case and security threat model 🎯 Users might see a need to start the post-quantum transition even while the concerns above are still on their mind, and hybridization can support that transition 🌈 It's worth noting that hybridization isn't necessary for every system. recommendations on system types, or on analysis methods for figuring that out, are out of scope for this document. once hybridization is found to be advantageous, you still have to decide how to hybridize. with lots of options on the table, this doc gives context on some of the trade-offs and nuances to consider 🧚

hybridizing digital signatures is subtle to design and implement. the hybrid signature may be expected to attest to both standard and post-quantum components, but those component signatures could potentially be separated from each other, and there's a risk of downgrade and stripping attacks 👀 There's also a whole range of requirements and properties that hybrid signatures may need to have, and this document goes through them. some of them are mutually exclusive, which is why it matters to think about your own use-case-specific requirements 💜

this document is about explaining a spectrum of hybrid signature scheme design categories and the different security goals for each. it's meant as a resource for designers and implementers, to help them decide which properties they do and don't need for their use case 💅 In terms of scope, it doesn't try to give concrete recommendations for any use case, and it intentionally doesn't propose concrete hybrid signature combiners or instantiations of them 🙅‍♀️ Like with the data authenticity guarantees of any digital signature, the security guarantees in this doc depend on correct provisioning and management of the keys involved, for example entity authentication and key revocation 🔑 Last thing: this document only considers scenarios with a single signer and a single verifier. constructions with multiple signers or verifiers are out of scope 🌸

more parts coming, so stay tuned 💖✨

1.1. Terminology ✨

Okay so, we're following the existing docs on hybrid terminology [RFC9794] and hybrid key encapsulation mechanisms (KEMs) [RFC9954] so everyone's speaking the same language 🗣️ We'll flag it whenever that isn't possible. We're specifically sticking with the definitions of 'post-quantum algorithm', 'traditional algorithm', and 'combiner'. And when we say 'certificate', we mean 'public-key certificate' as defined in [RFC4949] 🎀

Signature scheme: A signature scheme is built from three algorithms 💅

KeyGen() -> (pk, sk):
Sign(sk, m) -> (sig):
Verify(pk, sig, m) -> b:

KeyGen is a probabilistic key generation algorithm. It makes a public verifying key pk and a secret signing key sk 🔑

Sign is a probabilistic signature generation algorithm. It takes the secret signing key sk and a message m and spits out a signature sig. To keep the notation simple, this document treats the secret signing key sk as implicit, so we write Sign(m) -> (sig). If the message m has multiple fields, m1, m2, ..., mN, we write it as Sign(m) = Sign (m1, m2, ... mN) -> (sig) 🧚

Verify is the verification algorithm. It takes a public verifying key pk, a signature sig, and a message m, and outputs a bit b: b=1 means accept the signature for that message, and b=0 means reject it 🙅‍♀️

Hybrid signature scheme: Following [RFC9794], a hybrid signature scheme is "a multi-algorithm digital signature scheme made up of two or more component digital signature algorithms" 🌈 For security reasons, it often makes sense for the component schemes to rest on different cryptographic assumptions. But sometimes hybrids are motivated by other things, like interoperability between variants of the same scheme. In that case, both component schemes could be based on the same hardness assumption, like both post-quantum assumptions, or even the very same concrete assumption such as Ring Learning With Errors (R-LWE). We explicitly allow this 🫶

Here's the tea: unlike [RFC9794], we use the broader term 'hybrid signature scheme' instead of insisting on one post-quantum and one traditional algorithm (that's the Post-Quantum/Traditional (PQ/T) hybrid signature scheme). That way, combining several post-quantum algorithms is allowed too ✨ People sometimes use 'composite scheme' as a synonym for 'hybrid scheme'. But in [RFC9794], it means something specific: a scheme "exposed as a singular interface of the same type as the component algorithms". To avoid confusion, we'll skip the term 'composite scheme' entirely 🙈

Hybrid signature: A hybrid signature is the output of a hybrid signature scheme's signature generation. You might also see 'dual signature' used as a synonym. NIST defines a dual signature as "two or more signatures on a common message" [NIST_PQC_FAQ]. For the same reason as above, we'll avoid 'composite signature', even though it sometimes gets used as a synonym for 'hybrid/dual signature' 💜

Component (signature) scheme: Component signature schemes are the cryptographic algorithms that contribute to a hybrid signature scheme. They serve a similar purpose to what [RFC9794] describes. 'Ingredient (signature) scheme' can be used as a synonym 🍓

Next-generation algorithms: Following [RFC9954], next-generation algorithms are "algorithms that are not yet widely deployed but may eventually be widely deployed" 🦋 Hybrid signatures are mostly motivated by getting ready for the post-quantum transition or by long-term post-quantum deployment, which is why this document mentions post-quantum algorithms. That said, most of what's discussed here applies just as well to future transitions to other next-generation algorithms 🚀

Policy: Throughout this document, 'policy' covers things like a system policy that requires checking two signatures, an RFC description, or guidance documentation. Other phrases like 'security configuration settings' or similar wording might pop up too. For this document, we treat all of these as equivalent 📋

Artifact: An artifact is evidence that the sender meant to hybridize a signature, and that evidence sticks around even if a component signature gets removed. Artifacts can live at the algorithmic level (for example, inside the digital signature), at the protocol level (for example, inside the certificate), or at the system policy level (for example, inside the message). Artifacts should be easy for the receiver to spot in the case of signature stripping 🔍

Stripping attack: A stripping attack is when an adversary takes a message and hybrid signature pair and tries to submit a (possibly modified) version of that pair to a component algorithm verifier. That means the security is only based on whichever component scheme is left 😭 A classic example: a message and a hybrid signature made of concatenated post-quantum and traditional signatures. An adversary with a quantum computer just strips off the post-quantum component signature and sends the (maybe changed) message plus the traditional component signature to a traditional verifier. This could also include an authentic traditional certificate authority signature on a certificate that was originally hybrid-signed. The scary part is that an honest signer would still have attested to generating the signature 💀 Stripping attacks shouldn't be mixed up with component algorithm message forgery attacks, bestie 🙅‍♀️

Component algorithm message forgery attacks: A forgery attack is when an adversary tries to forge a (non-hybrid) signature on a message using the public key of a component algorithm. A common example is a quantum attacker breaking the key of a traditional component algorithm and forging a message and signature pair 👀 Message forgery attacks can be formalized with experiments like Existential Unforgeability under Chosen Message Attack (EUF-CMA) [EUFCMA]. What's different in component algorithm message forgery attacks is that the key gets accepted for both hybrid and single algorithm use. We dig into this more in Section 5 🔥

1.2. Motivation for Use of Hybrid Signature Schemes 🌸

Before we get into the design goals for hybrid digital signatures, let's look at why we'd want them at all. Lots of the arguments hold for hybrid algorithms in general, so we again point you to [RFC9954], which sums them up really well 💖 We'll also spell out the motivation specifically for hybrid signatures here.

1.2.1. Complexity 🧩

Next-generation algorithms and their underlying hardness assumptions are often more complicated than traditional ones. For example, the signature scheme Module-Lattice-Based Digital Signature Algorithm (ML-DSA) [MLDSA] uses the well-known Fiat-Shamir transform [FS] to build the signature scheme. It also relies on rejection sampling, which is known to leak cache side channel information (though no known attack has exploited that yet) 😬 Then there's the signature scheme FALCON [FALCON], which uses complex sampling during signature generation. On top of that, attacks against the next-generation multivariate schemes Rainbow [RAINBOW] and Great Multivariate Short Signature (GeMSS) [GEMSS] might worry conservative adopters of other algorithms, and that could slow adoption down 🐢

So some next-generation algorithms carry a higher risk of implementation mistakes and parameter revisions than traditional algorithms like RSA. RSA is pretty simple to understand and explain, but over its lifetime it has picked up multiple attacks and refinements. Examples include adding requirements on how padding and keys are chosen, and implementation issues like cross-protocol attacks (which can be caused by component algorithm forgeries). So even a relatively simple algorithm can end up with subtleties and caveats around implementation and use over time 🕰️ Given how complex next-generation algorithms are, we have to account for the chance that these discoveries and caveats will pop up.

To be fair, some next-generation algorithms have gotten a lot of analysis, for example following the attention they got during the NIST Post-Quantum Cryptography Standardization Project [NIST_PQC_FAQ]. Still, if and when more information about caveats and implementation issues comes out, it's quite possible that a vulnerability will weaken security rather than fully "break" the algorithm. And that weakening may be offset if a hybrid approach was used 🛡️

1.2.2. Time ⏳

In big systems, like national systems, space systems, large healthcare support systems, and critical infrastructure, acquisition and procurement can take years. Swapping out an algorithm might be hard or even practically impossible 😩 Long-term commitments make post-quantum algorithm selection urgent right now. For instance, that's true when generating root certificates with their long validity windows. And for some sectors, checking past authenticity matters a lot (think legal, financial, auditing, and governmental systems). So there's a need to move some systems to post-quantum signature algorithms imminently. But, as we said above, we also need to stay aware of potential hidden subtleties in next-generation algorithms' resistance to standard attacks, especially where replacing algorithms is difficult. This mix of time pressure and complexity pushes some transition designs toward hybridization 💜

1.3. Goals 🎯

There are a bunch of security and usability goals that hybridization can help with. Here's a quick summary of them, plus a heads-up on where goals clash. Sometimes achieving one goal rules out another one, like backwards compatibility 🙃

1.3.1. Hybrid Authentication 🔐

One goal of hybrid signature schemes is security. As defined in [RFC9794], a hybrid signature scheme ideally achieves 'hybrid authentication'. That means (cryptographic) authentication is achieved by the hybrid signature scheme as long as at least one component signature algorithm remains 'secure' 🫶 Other goals can compete with this one, though. Backwards compatibility is one of them. That's the property where a hybrid signature can be verified by only verifying one component signature (see Section 1.3.5) 👑 Hybrid authentication is an umbrella term covering more specific ideas about hybrid signature security, like 'hybrid unforgeability', which we'll get into next 🌈

1.3.1.1. Hybrid Unforgeability

Okay so hybrid unforgeability is a special flavor of hybrid authentication 💅✨ The security assumption for the scheme (think EUF-CMA 🔐) stays intact as long as at least one of the component schemes still holds that security assumption. Bestie, that's giving backup plan energy 🫶 For example, the concatenation combiner in [HYBRIDSIG] is 'hybrid unforgeable' 🎀 As I mentioned above, this can clash with backwards compatibility 🙈 That's where the EUF-CMA security of the hybrid signature only rests on the security of one of the component schemes, instead of on both. The dual message combiner using nesting in [HYBRIDSIG] is a good example of that 💀 For more details, check out Section 1.3.5. 🦋

Some use cases run a hybrid scheme where EUF-CMA security is only assumed for one component scheme 🌸 These usually use hybrid techniques for their 'functional transition' pathway support. For example, hybrid signatures can be a transition step for gradual post-quantum adoption 🧚 That keeps things interoperable when a system has both verifiers that only support traditional signatures and verifiers that have been upgraded to support post-quantum signatures 🌈

Now the other vibe 👑 In use cases where a hybrid scheme assumes EUF-CMA security for both component schemes, with no prioritization between them, hybrid techniques can cover both functional transition and security transition 😭 (Security transition means transitioning so security holds even when it isn't known which algorithm should be relied upon 💜)

1.3.2. Proof Composability

Under proof composability, the component algorithms get combined in a way where you can prove a security reduction from the security properties of a hybrid signature scheme to the properties of the respective component signature schemes 🦋 It can also reach other building blocks like hash functions, key derivation functions, and so on ✨ Otherwise you'd need a brand new proof of security, and there's a lack of assurance that the combo builds on the standardization processes and analysis already done on the component algorithms 😩 The resulting hybrid signature would basically be an entirely new algorithm of its own 🔥 The more entangled the component signature schemes are, the more likely it is that a whole new proof is needed, which means not meeting proof composability 💀

1.3.3. Weak Non-Separability

Non-separability was one of the earliest properties of hybrid digital signatures to get discussed [HYBRIDSIG] 🌸 It's the guarantee that an adversary can't simply "remove" one of the component signatures without leaving evidence behind 🕵️‍♀️ For example, there are artifacts that a carefully designed verifier may be able to identify, or that show up in later audits 🔍 This was later named Weak Non-Separability (WNS) [HYBRIDSIGDESIGN] 💖 Note that WNS doesn't stop an adversary from maybe creating a valid component digital signature out of a hybrid one (a signature stripping attack) 😬 What it does mean is that such a digital signature will contain artifacts of the separation 🎀 So authentication that's normally assured by correct verification of digital signature(s) now also depends on further investigation on the receiver side, which can go way beyond traditional signature verification behavior 🫠

Here's the intuition: say a message contains a context note on hybrid authentication, and then all component algorithms sign it as part of the hybrid signature scheme 💜 If an adversary removes one component signature but not the other, artifacts in the message itself can point to a possible hybrid signature, like a label saying "this message must be hybrid-signed" 🏷️ That might be a countermeasure against stripping attacks if the verifier expects a hybrid signature scheme to have this property 🛡️ But now the responsibility for signature validity isn't just on the correct format of the message, like in a traditional signature security guarantee; it's on the precise content too 😵‍💫

1.3.4. Strong Non-Separability

Strong Non-Separability (SNS) is a stronger version of WNS, introduced in [HYBRIDSIGDESIGN] 💪✨ SNS guarantees that an adversary can't take a hybrid signature (and message) as input and output a valid component signature (and potentially a different message) that verifies correctly 🙅‍♀️ In other words, if you separate the hybrid signature into component signatures, the component signature will fail verification (of the component signature scheme) entirely 💥 So authentication comes from the sender to the receiver through correct verification of the digital signature(s), just like in traditional signature security experiments 🫶 It doesn't depend on other components, like message content checking, or protocol-level aspects, like public key provenance 🌷

Let's compare WNS and SNS with an example 🍓 Take component algorithms Sigma_1.Sign and Sigma_2.Sign, where the hybrid signature is computed as a concatenation (sig_1, sig_2), with sig_1 = Sigma_1.Sign(hybridAlgID, m) and sig_2 = Sigma_2.Sign(hybridAlgID, m) 🧁 In this case, a new message m' = (hybridAlgID, m), along with signature sig_1 and Sigma_1.pk, with the hybrid artifact embedded in the message instead of the signature, could be correctly verified 😳 The separation would be identifiable through further investigation, but the signature verification itself wouldn't fail 🙃 So this case shows WNS (assuming the verification algorithm is defined accordingly) but not SNS 🌈

Some work [COMP-MLDSA] has looked at relying on public key certificate chains to explicitly define hybrid use of the public key 🔗 Namely, Sigma_1.pk can't be used without Sigma_2.pk 🙅‍♀️ This pushes the hybrid artifacts up into the protocol and system level, and makes things depend on the security of other verification algorithms (namely the ones in the certificate chain) 😭 It also means security analysis of a hybrid digital signature has to look at key provenance too, so it's not just "is a valid public key being used?" but "how were its hybridization and hybrid artifacts managed through the entire chain?" 🧐 External dependencies like this may mean the hybrid artifacts live outside the scope of the signature algorithm itself 🫧 SNS may potentially be achievable based on dependencies at the system level 👑

1.3.5. Backwards and Forwards Compatibility

Backwards compatibility means a hybrid signature can be verified by only verifying one component signature, which lets the scheme be used by legacy receivers 🕰️ Generally this means verifying the traditional component signature scheme, potentially ignoring the post-quantum signature entirely 🎀 This gives you an option to transition sender systems to post-quantum algorithms while still supporting select legacy receivers 🦋 And notably, this is a verification property: the sender has provided a hybrid digital signature, but the verifier is allowed, due to internal policy and/or implementation, to only verify one component signature 💅

Forwards compatibility has also been considered in hybrid proposals [NC-HYBRID-AUTH] 🔮 It assumes hybrid signature schemes will be used for some time, but that eventually all systems will move to using only one algorithm (especially only one post-quantum algorithm) 🌸 Since this is very similar to backwards compatibility, it may also imply separability of a hybrid algorithm; however, it could also just imply the capability to support separate component signatures 🧩 So the key difference between backwards and forwards compatibility is that backwards compatibility may be needed for legacy systems that can't use and/or process hybrid or post-quantum signatures, whereas with forwards compatibility, the system has those capabilities and can choose what to support (for efficiency reasons, for example) ⚡

Ideally, backwards and forwards compatibility is achieved using redundant information as little as possible, as noted in [RFC9954] 🫶

1.3.6. Simultaneous Verification

Simultaneous Verification (SV) builds on SNS and was first introduced in [HYBRIDSIGDESIGN] 🎬 SV requires that the entire hybrid signature (e.g., all component signature elements) needed for a successful verification is present in the signature presented for verification, AND that verification of both component algorithms happens roughly simultaneously 😤 Namely, "missing" information needs to be computed by the verifier, so a normally functioning verification algorithm can't "quit" the verification process before the hybrid signature elements attesting for both component algorithms are verified 🙈 This may also cover some error-injection and similar attacks, where an adversary tries to make an otherwise honest verifier skip component algorithm verification 🚫 SV mimics traditional digital signature guarantees, basically making sure the hybrid digital signature behaves as a single algorithm instead of two separate component stages ✨ Put another way: under an SV guarantee, an otherwise honest verifier can't stop the hybrid verification after one component algorithm succeeds without also knowing whether the other component succeeded 🛑 Note that SV doesn't prevent dishonest verification, like if a verifier maliciously implements a customized verification algorithm designed to subvert the hybrid verification process, or skips signature verification altogether 😈

1.3.7. Hybrid Generality

Hybrid generality means a general signature combiner is defined based on the inherent and common structures of component digital signature "categories" 🌈 For instance, since multiple signature schemes use a Fiat-Shamir transform, a hybrid scheme built on that transform can be made that generalizes to all such signatures 🧠 This generality can also lead to simplified constructions, whereas more tailored hybrid variants might be more efficient in terms of sizes and performance ⚡

1.3.8. High Performance

Similar to the performance goals noted for hybridization of other cryptographic components [RFC9954], hybrid signature constructions are expected to be as performant as possible 🏎️ For most hybrid signatures, that means the computation time should only minimally exceed the sum of the component signature computation times ⏱️ Performance of any variety may come at the cost of other properties, like hybrid generality 💭

1.3.9. High Space Efficiency

Hybrid signature constructions are expected to be as space performant as possible 📦 This includes messages (since they might grow if artifacts are used), public keys, and the hybrid signature itself 🗂️ For the hybrid signature, size should be no more than minimally larger than the signature size of the two component signatures 🎀 In some cases, a hybrid signature may be smaller than the concatenation of the two component signatures 🤯

1.3.10. Minimal Duplicate Information 🎀

okay so bestie, duplicated info is basically the enemy of efficiency 💅 you should avoid it whenever you can, no cap. this can show up as repeated stuff inside hybrid certificates, or when you're sending component certificates alongside the hybrid one (like for backwards and forwards compatibility 🦋). it also happens when you send multiple public keys or signatures for the same component algorithm, and yeah, that's giving clutter 🙈

2. Non-Separability Spectrum 🌈

okay this one is my fave lowkey 😭 non-separability isn't one single definition, it's a whole spectrum of how hard it is to separate the parts of a hybrid. Figure 1 shows it all 👑

| ----------------------------------------------------------|
| *No Non-Separability*
|
| No artifacts exist.
| ----------------------------------------------------------|
| *Weak Non-Separability*
|
| Artifacts exist in the message, signature, system,
| application, or protocol.
| ----------------------------------------------------------|
| *Strong Non-Separability*
|
| Artifacts exist in the hybrid signature.
| ----------------------------------------------------------|
| *Strong Non-Separability with Simultaneous Verification*
|
| Artifacts exist in the hybrid signature, and verification
| or failure of both components occurs simultaneously.
| ----------------------------------------------------------|
V

Figure 1: Spectrum of Non-Separability from Weakest to Strongest

at one end you've got schemes where someone can strip off one component signature and the verifier just... doesn't notice 😬 like plain concatenation of signatures with no artifacts at all. nested signatures can land here too, depending on whether the inner or the outer one gets stripped off with no artifacts left behind 💀

next up is weak non-separability 🦋 if one component signature gets removed from a hybrid signature, artifacts of the hybridization still stick around (in the message, the signature, the protocol level, etc). this may let the verifier catch that a component was stripped, but it really depends on the type of artifact and permissions ngl. like, if a message has a label artifact saying "This message must be signed with a hybrid signature", the system has to be allowed to look through the message contents for it 🔍 whether a hybrid signature gets (Weak/Strong) Non-Separability can also depend on the implementation and policy of the protocol or app on the verifier side. and those policies might be kinda fuzzy to the sender, so the kind of authenticity the receiver gets is unclear 🫠 with nested signatures, a verifier could be tricked into reading a new message as the message plus inner signature and only verifying the outer one. in that case the inner signature is the artifact ✨

third on the spectrum is Strong Non-Separability 👑 here, detecting separation depends on artifacts in the signature itself. unlike weak non-separability, where artifacts can live in the message, the certificate, or other non-signature parts, this one ties way closer to the classic algorithm security notions (like EUF-CMA), where security depends on the signature algorithm's internal construction and how it's verified. so the verifier can spot artifacts at the algorithm level during verification 🤯 for example, the signature itself might encode the fact that a hybrid signature scheme was used. examples of this kind can be found in [HYBRIDSIGDESIGN] 📚

and for the most demanding one, Strong Non-Separability with Simultaneous Verification 💖 verification only succeeds when both component signatures are present and the verifier has verified both. nothing about whether the component signatures are valid leaks to the receiver during verification until both verify (or a failure may or may not be traceable to one specific component algorithm). this is the most like traditional digital signatures, where the result is either a full positive verification or a failure if the signature isn't valid 🎀 for fused hybrid signatures, a full signature means both component algorithms are fused together, so this construction has the potential to hit the strongest non-separability notion: all-or-nothing verification, no matter what an adversary does 🔥 examples of algorithms with this security can be found in [HYBRIDSIGDESIGN] 🫶

3. Artifacts 🧚

hybridization gets a boost from artifacts, which are evidence that the sender meant to make stripping attacks riskier 🛡️ but where that evidence lives matters a LOT (in the message, in the signature, or at the protocol level instead of the algorithm level). even popular hybrid approaches like concatenation aren't tied to just one type of security (like WNS or SNS), which can make comparisons super confusing 😵‍💫 so in this section we cover where artifacts can go and walk through a high-level comparison of some hybrid categories to show how placement changes within one approach. artifact location is tied to the non-separability notions above, so picking a security guarantee and a general hybrid approach also means picking exactly where the artifacts go 💅

3.1. Artifacts vs. Separability 💜

quick reminder: non-separability is a security notion of the signature scheme and isn't directly about artifacts, but artifacts can be used to detect separation 🔍 for example, under strong non-separability the scheme fails verification if separation happens, while under weak non-separability some artifacts exist when separation happens but verification doesn't necessarily fail. the verifier could just ignore the artifact, so the scheme only gets weak non-separability and not strong 🙃 but the artifact is still there and could be found if someone investigates. under weak non-separability, detecting separation might depend on non-cryptographic configurations or other dependencies. also, strong and weak non-separability are properties of the signature scheme, while artifacts aren't necessarily in the signature. they can show up in the signed message, the certificate, the protocol, or the policy (which is why they aren't necessarily tied to the SNS and WNS notions) 🌸 artifacts can still be useful (though it depends on system config) even when separable signatures are used 💖

3.2. Artifact Locations 🦋

artifacts can live all over the place, from inside the message all the way to the signature algorithm, the protocol level, and even policy, as shown in Table 1 ✨ for example, one artifact location could be the message being signed, like a label artifact. depending on the hybrid type, an attacker might be able to strip that away 😬 like, a quantum attacker could strip the post-quantum signature off a concatenated dual signature, and since they can forge the traditional signature, they could also remove the label artifact from the message. so for lots of apps and threat models, an artifact in the message might not be enough against stripping attacks 🙈 another artifact location could be the public key certificates described in [COMP-MLDSA]. in that case the artifacts are still there even if a stripping attack happens 🫶 and in yet another case, artifacts can come through the fused hybrid method, making them part of the signature at the algorithm level. in this latter case, an adversary can't strip one component signature or use a component of the hybrid signature to forge a component algorithm. these signatures provide SNS 👑 which also means the hybridization artifacts are absolute: verification fails if an adversary tries to remove them 🔥

eventual security analysis might factor into choosing between levels 🧐 for example, if the hybrid scheme's security depends on system policy, then the crypto analysis has to rely on those specific policies, and it might not be possible to describe the scheme's security on its own. in that case you have to look at how a particular implementation or use is configured to assess security, which could raise the risk of unknown and unanticipated vulnerabilities, no matter which algorithms are in use 😭

      +========================================+===========+
      | Location of Artifacts of Hybrid Intent | Level     |
      +========================================+===========+
      | Signature                              | Algorithm |
      +----------------------------------------+-----------+
      | Certificate                            | Protocol  |
      +----------------------------------------+-----------+
      | Algorithm agreement / negotiation      | Protocol  |
      +----------------------------------------+-----------+
      | Message                                | Policy    |
      +----------------------------------------+-----------+

                Table 1: Artifact Placement Levels

3.3. Artifact Location Comparison Example ✨

Okay bestie, this part shows how artifacts can end up in different spots even when you're using the same general approach 🧩 We're looking at three categories: concatenation, nesting, and fusion. Picking one approach doesn't automatically lock in a specific non-separability notion, and the choice is subtle because hybrid artifacts are tied to those guarantees 💅 Also, this comparison shows that two different hybrid approaches can put their artifacts in the exact same place 👀

Here's a quick recap of the categories before we get to Table 2 🎀

Concatenation 🔗: for component algorithms Sigma_1.Sign and Sigma_2.Sign, the hybrid signature is a concatenation (sig_1, sig_2), where sig_1 = Sigma_1.Sign(hybridAlgID || m) and sig_2 = Sigma_2.Sign(hybridAlgID || m).
Nesting 🪆: for the same component algorithms, the hybrid signature is built in layers as (sig_1, sig_2). For example, sig_1 = Sigma_1.Sign(hybridAlgID || m) and sig_2 = Sigma_2.Sign(hybridAlgID || (m || sig_1)).
Fused hybrid 💫: for the same component algorithms, the hybrid signature is one single signature sig_h that can't be cleanly split back into one or more valid component constructs. For example, if both schemes are built with the Fiat-Shamir transform, the component signatures include responses r_1 and r_2 and challenges c_1 and c_2, where c_1 and c_2 are hashes over the respective commitments comm_1 and comm_2 (and the message). A fused hybrid signature could contain the component responses r_1 and r_2 plus one challenge c computed as a hash over both commitments, i.e., c = Hash((comm_1 || comm_2) || Hash2(message)). So c doesn't belong to either component signature but to both, which means the signatures are 'entangled' 🥹

Now, the big table of where things land 📋

    +====+=========================+==================================+
    | #  | Location of Artifacts   | Category                         |
    |    | of Hybrid Intent        |                                  |
    +====+=========================+==================================+
    |    |                         | *Concatenated*                   |
    +----+-------------------------+==================================+
    | 1  | None                    | No label in message, public keys |
    |    |                         | are in separate certificates     |
    +----+-------------------------+----------------------------------+
    | 2  | In message              | Label in message, public keys    |
    |    |                         | are in separate certificates     |
    +----+-------------------------+----------------------------------+
    | 3  | In certificate          | No label in message, public keys |
    |    |                         | are in combined certificate      |
    +----+-------------------------+----------------------------------+
    | 4  | In message and          | Label in message, public keys    |
    |    | certificate             | are in combined certificate      |
    +----+-------------------------+==================================+
    |    |                         | *Nested*                         |
    +----+-------------------------+==================================+
    | 5  | In message              | Label in message, public keys    |
    |    |                         | are in separate certificates     |
    +----+-------------------------+----------------------------------+
    | 6  | In certificate          | No label in message, public keys |
    |    |                         | are in combined certificate      |
    +----+-------------------------+----------------------------------+
    | 7  | In message and          | Label in message, public keys    |
    |    | certificate             | are in combined certificate      |
    +----+-------------------------+==================================+
    |    |                         | *Fused*                          |
    +----+-------------------------+==================================+
    | 8  | In signature            | Public keys are in separate      |
    |    |                         | certificates                     |
    +----+-------------------------+----------------------------------+
    | 9  | In signature and        | Label in message, public keys    |
    |    | message                 | are in separate certificates     |
    +----+-------------------------+----------------------------------+
    | 10 | In signature and        | Public keys are in combined      |
    |    | certificate             | certificate                      |
    +----+-------------------------+----------------------------------+
    | 11 | In signature and        | Label in message, public keys    |
    |    | message and certificate | are in combined certificate      |
    +----+-------------------------+----------------------------------+

     Table 2: Artifact Locations Depending on the Hybrid Signature Type

So, as Table 2 shows, concatenation may sound like one single combiner, but there are actually several possible artifact locations depending on implementation choices 🌈 Artifacts help support detection in the case of stripping attacks, which means different artifact locations imply different overall system implementation considerations for achieving that detection 🕵️‍♀️

Case 1 gives the weakest hybrid identification guarantees 😬 There are no prescribed artifacts, so non-separability is not achieved. That said, it doesn't mean every concatenation implementation fails to get non-separability, so it's advisable for implementers to be transparent about where their artifacts live 🫶

In cases 2 and 5, the artifacts sit inside the message 🙈 This is a big deal because the message's authenticity relies on the signature being valid, but the artifact location means the signature in turn relies on the authentic message content (the artifact label). That's a risk of circular dependency! Alternatives like cases 3, 4, 6, and 7 break this loop by provisioning keys in a combined certificate 🔁➡️✅

Another vibe from this comparison: artifact locations can be pretty similar across approaches. Cases 3 and 6, for instance, both keep artifacts in the certificate 👯‍♀️ These are high-level examples, so you'd need more specification on concrete schemes in each category before prescribing non-separability guarantees. Still, it hints at a strong similarity between those guarantees. Comparing like this gives you a systematic decision process: you check and compare security, and if schemes match on the desired security goal, you can pick between them based on performance and implementation ease 🧠✨

One last observation: different combiners can change the security analysis assumptions in a system 🧐 Cases 3, 4, 6, and 7 all push artifacts (and therefore the signature validity) into the certificate chain. So the entire chain must also use a similar combiner if you want a straightforward security argument 🔐 The other cases, like 8, 9, 10, and 11, put artifacts inside the signature itself. Those look the most like traditional schemes, where message authenticity depends on signature validity 💜

4. Need for Approval Spectrum ✨

okay bestie, so in real life, hybrid digital signatures usually have to play nice with standards 📜, especially when you're required to use FIPS-approved software modules 🔐. The same goes for any guidance or policy that says at least one component algorithm in the hybrid scheme has to pass some kind of certification, while saying nothing about the other one. NIST says this in [NIST_PQC_FAQ] (emphasis added), and I'm screaming because it's so relevant 😭:

|  Assume that in a [hybrid] signature, _one signature is generated
|  with a NIST-approved signature scheme as specified in FIPS 186,
|  while another signature(s) can be generated using different
|  schemes_, e.g., ones that are not currently specified in NIST
|  standards ... _[hybrid] signatures can be accommodated by current
|  standards in "FIPS mode", as defined in FIPS 140, provided at
|  least one of the component methods is a properly implemented,
|  NIST-approved signature algorithm_. For the purposes of FIPS 140
|  validation, any signature that is generated by a non-approved
|  component scheme would not be considered a security function,
|  since the NIST-approved component is regarded as assuring the
|  validity of the [hybrid] signature.

This document doesn't give a formal reading of the NIST statement 🙈. We just use it as motivation to point out some things implementers of hybrid signature schemes might wanna think about when a guidance doc says 1) the signature scheme for one of the component algorithms must be approved, and 2) that algorithm must be a well-implemented or certified implementation. This kind of need for approval (basically, a requirement an implementer follows about approving or certifying the software module behind a hybrid or its component algorithms) can totally shape which hybrid signature schemes you should even be looking at 💅.

So there's a whole spectrum of approval 🌈. Developers can ask whether they're using at least one approved component algorithm implementation (a 1-out-of-n approved software module), or whether every single component algorithm implementation is individually approved (an all approved software module). It's giving layers.

We break down the different flavours of approval for the hybrid combiners, where "approval" means a software implementation of a component algorithm can be used unmodified to create the hybrid signature. This can be tied to whether a hybrid combiner is likely to need its own dedicated certification 🎀.

      | ---------------------------------------------------------|
      | *New Algorithm*
      |
      | New signature scheme based on a selection of hardness
      | assumptions.
      |
      | Separate approval needed.
      | ---------------------------------------------------------|
      | *No Approved Software Module*
      |
      | Hybrid combiner supports security analysis that can be
      | reduced to approved component algorithms, potentially
      | changing the component implementations.
      |
      | Uncertainty about whether separate approval is needed.
      | ---------------------------------------------------------|
      | *1-out-of-n Approved Software Module*
      |
      | Combiner supports one component algorithm and
      | implementation in a black-box way but potentially
      | changes the other component algorithm implementation(s).
      |
      | No new approval needed if the black-box component
      | (implementation) is approved.
      | ---------------------------------------------------------|
      | *All Approved Software Modules*
      |
      | Hybrid combiner acts as a wrapper, fully independent of
      | the component signature scheme implementations.
      |
      | No new approval needed if at least one component
      | implementation is approved.
      | ---------------------------------------------------------|
      V

                    Figure 2: Need for Approval Spectrum

The first combiner on the list is a brand new construction whose security reduces to different hardness assumptions 🧚. It doesn't have to reduce to approved (or even existing) signature schemes. This singular new algorithm mixes traditional and next-generation principles, which is very main character of it 👑.

Next up is a combiner that might take inspiration from existing, approved signature schemes, so its security can be reduced to the security of those approved algorithms ✨. The catch is that it may alter the implementations. So it's honestly unclear whether new approval would be needed, since that depends on the combiner and what's changed. This case might point to a difference between needing fresh approval of the algorithm(s) and needing approval of the implementation(s) 🤔.

The 1-out-of-n combiner uses at least one approved algorithm implementation in a black-box way (meaning the software module for that algorithm isn't modified) 🦋. It may change the specifics of the other component algorithm implementations. If the premise is that no new approval is needed as long as at least one component is approved, then this is likely considered sufficient 💜.

In an all-approved combiner, every algorithm implementation is used in a black-box way 🍓. A concatenation combiner is a simple example, where a signature is valid if all the component signatures are valid. Since every algorithm implementation is approved, a requirement that at least one of the hybrid's component algorithms is approved would be satisfied 🌸.

5. EUF-CMA Challenges

okay so unforgeability for hybrid signature schemes is way more nuanced than for single-algorithm schemes 🥺.

Under the traditional EUF-CMA security assumption, an adversary requests signatures for messages of their choosing, and they win if they can produce a valid signature for a message that wasn't part of an earlier request 😈. EUF-CMA can be seen as applying to a hybrid signature scheme the same way it applies to single-algorithm schemes. The most straightforward extension of the traditional EUF-CMA game would be that an adversary requests hybrid signatures for messages they pick, and wins if they can produce a valid hybrid signature for a message that wasn't part of an earlier request. But a hybrid construct adds several layers of nuance 💅.

Take, for example, a simplistic hybrid approach using concatenated component algorithms. If the hybrid signature gets stripped, so that a single component signature is submitted to that component's verification algorithm along with the message that was signed by the hybrid scheme, the result would be an EUF-CMA forgery for the component signature 💀. Why? Because the component signing algorithm was never called for that message; the hybrid signing algorithm was used to generate the signature. This is an example of a component algorithm forgery, which may lead to a cross-algorithm attack or a cross-protocol attack 🚨.

The component algorithm forgery verifier target doesn't have to be the intended recipient of the hybrid-signed message. It might even be in a totally different system 👀. This is especially an issue for concatenated or nested hybrid signature schemes, where individual component verification could be possible. Also, policy enforcement of hybrid verification does not fix the problem for the intended message recipient: the component algorithm forgery could happen on any system that accepts the component keys 😭.

Informally, EUF-CMA security assumes an adversary can request signatures on messages of their choosing and wins if they can produce a valid signature for a message that wasn't part of an earlier request. So the matching EUF-CMA guarantee for hybrids can be defined so that an adversary can request hybrid signatures for messages of their choosing and wins if they can produce a valid hybrid signature for a message that wasn't part of an earlier request. To actually meet this guarantee, some implicit requirements have to hold. Basically, either component algorithm forgeries (and cross-protocol attacks) must be impossible in the use case, or the hybrid signature choice must be strongly non-separable 🔒. Otherwise, component algorithm forgeries change which EUF-CMA properties you actually get, and system designers and managers should keep that in mind when picking a hybrid approach for their use case 🧐.

There are a couple of ways to ease this issue, as noted above. One is restricting key reuse. As described in [COMP-MLDSA], prohibiting hybrid algorithm and component algorithm signers and verifiers from using the same keys can help make sure a component verifier can't be tricked into verifying the hybrid signature 🙅‍♀️. That effectively puts component algorithm forgeries out of scope for a use case. One way to restrict key reuse is through allowed key use descriptions in certificates. Prohibiting key reuse does lower the risk of these forgeries, and it's the mitigation described in [COMP-MLDSA], but it's still a policy requirement and not a cryptographic assurance 📝. Component algorithm forgery attacks may still be possible if the policy isn't followed, or is followed inconsistently across all the entities that might verify signatures with those keys. That has to be accounted for in any security analysis. And since cryptographic provable security modeling hasn't historically accounted for key reuse this way, you shouldn't assume that systems with existing analyses are robust to this issue 🫣.

The other approach for easing the component algorithm forgery risk is choosing a hybrid signature scheme that provides strong non-separability ✨. With this approach, the hybrid signature can't be separated into component algorithm signatures that will verify correctly. That blocks the signature separation the component algorithm forgery attack needs in order to work 🛡️.

Weak non-separability is NOT enough for mitigating component algorithm forgery risks, bestie 🙅‍♀️. As noted in Section 9.3 of [COMP-MLDSA], when a hybrid algorithm selection only gives weak non-separability, key reuse should be avoided (as mentioned above) to mitigate the risk of introducing EUF-CMA vulnerabilities for component algorithms.

6. Discussion of Advantages and Disadvantages

The design of hybrid signature schemes, and so their security guarantees, depends heavily on the properties the application or protocol using them needs 🎀. It seems like not every goal can be achieved at the same time, as shown below.

6.1. Backwards Compatibility vs. SNS

okay this one's a tea ☕. There's an inherent mutual exclusion between backwards compatibility and SNS (strong non-separability) 💔. While WNS (weak non-separability) allows a valid separation under leftover artifacts, SNS will ensure verification fails if a receiver tries to separate the signature 🙈.

6.2. Backwards Compatibility vs. Hybrid Unforgeability 🎀

Okay so this one is a real plot twist, bestie 😭. Backwards compatibility and hybrid unforgeability have an inherent mutual exclusion, and it kicks in when you actually act on backwards compatibility. We already brushed past this earlier, and now it's time to give it the spotlight it deserves 💅.

The whole point of backwards compatibility is usually to let legacy systems, with no software change at all, process hybrid signatures. So every difference between the legacy signature format and the hybrid signature format has to be allowed to be ignored, and that includes skipping verification of the signatures sitting alongside the classical one 🙈. Which means that if a system skips a component signature, security does not rely on the security of all component signatures. Yikes, right? 💀

Here's the lowkey clever part: this mutual exclusion shows up at the verification stage 🦋. A hybrid signature that's verified by a system that can process both component schemes can still deliver hybrid unforgeability, even if another legacy system, looking at that very same hybrid signature, loses that property. Same signature, different guarantees, depending on who's checking. Iconic and also a little bit terrifying 😭✨.

6.3. Simultaneous Verification vs. Low Need for Approval 🌸

Next up, the relationship between simultaneous verification and approval. Hybrid algorithms that achieve simultaneous verification tend to fuse, or as the original puts it, "entangle", the verification of their component algorithms. The verification operations from the different component schemes end up depending on each other in some way 🫶.

Because of that, there may be a natural connection between achieving simultaneous verification and a higher need for approval 🔥. Now for the contrasting example. NIST accommodates concatenating a FIPS-approved signature with another signature that might not be FIPS approved, and it does this without any artifacts in FIPS 140 validation [NIST_PQC_FAQ]. The catch? Because the component signatures are verified separately, it is not possible to enforce simultaneous verification 🧚. Two very different vibes, bestie 💜.

7. Security Considerations 💖

This document discusses digital signature constructions that may be used in security protocols 🔐. It is an Informational document and does not directly affect any other documents 🌈. The security considerations for any specific implementation or incorporation of a hybrid scheme should be discussed in the relevant specification documents 📜. So if you're building something on top of this, go check those specs, no cap 👑.

8. IANA Considerations 🍓

This document has no IANA actions 🧁. Nothing to register, nothing to update, we're all good 💅.

9. References 📚

9.1. Normative References 💜

[RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
           FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
           <https://www.rfc-editor.org/info/rfc4949>.

[RFC9794]  Driscoll, F., Parsons, M., and B. Hale, "Terminology for
           Post-Quantum Traditional Hybrid Schemes", RFC 9794,
           DOI 10.17487/RFC9794, June 2025,
           <https://www.rfc-editor.org/info/rfc9794>.

[RFC9954]  Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid Key
           Exchange in TLS 1.3", RFC 9954, DOI 10.17487/RFC9954, July
           2026, <https://www.rfc-editor.org/info/rfc9954>.

9.2. Informative References 🦋

[COMP-MLDSA]
           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, 21 April 2026,
           <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
           pq-composite-sigs-19>.

[EUFCMA]   Green, M., "EUF-CMA and SUF-CMA",
           <https://blog.cryptographyengineering.com/euf-cma-and-suf-
           cma/>.

[FALCON]   Fouque, P., Hoffstein, J., Kirchner, P., Lyubashevsky, V.,
           Pornin, T., Prest, T., Ricosset, T., Seiler, G., Whyte,
           W., and Z. Zhang, "FALCON: Fast-Fourier Lattice-based
           Compact Signatures over NTRU", Specification v1.2, 10
           January 2020, <https://falcon-sign.info/falcon.pdf>.

[FS]       Fiat, A. and A. Shamir, "How To Prove Yourself: Practical
           Solutions to Identification and Signature Problems",
           Advances in Cryptology -- CRYPTO' 86, Lecture Notes in
           Computer Science, vol. 263, pp. 186-194,
           DOI 10.1007/3-540-47721-7_12, 1986,
           <https://doi.org/10.1007%2F3-540-47721-7_12>.

[GEMSS]    "GeMSS: A Great Multivariate Short Signature", 15 April
           2020, <https://www-polsys.lip6.fr/Links/NIST/
           GeMSS_specification_round2_V2.pdf>.

[HQC_CVE]  NIST, "CVE-2024-54137: liboqs has a correctness error in
           HQC decapsulation", 6 December 2024,
           <https://nvd.nist.gov/vuln/detail/CVE-2024-54137>.

[HYBRIDSIG]
           Bindel, N., Herath, U., McKague, M., and D. Stebila,
           "Transitioning to a Quantum-Resistant Public Key
           Infrastructure", Cryptology ePrint Archive, Paper
           2017/460, May 2017, <https://eprint.iacr.org/2017/460>.

[HYBRIDSIGDESIGN]
           Bindel, N. and B. Hale, "A Note on Hybrid Signature
           Schemes", Cryptology ePrint Archive, Paper 2023/423, March
           2023, <https://eprint.iacr.org/2023/423>.

[KYBERSLASH]
           Bernstein, D. J., Bhargavan, K., Bhasin, S.,
           Chattopadhyay, A., Chia, T. K., Kannwischer, M. J.,
           Kiefer, F., Ravi, P., and G. Tamvada, "KyberSlash:
           Exploiting secret-dependent division timings in Kyber
           implementations", Cryptology ePrint Archive, Paper
           2024/1049, June 2024, <https://eprint.iacr.org/2024/1049>.

[MLDSA]    NIST, "Module-Lattice-Based Digital Signature Standard",
           NIST FIPS 204, DOI 10.6028/NIST.FIPS.204, August 2024,
           <https://nvlpubs.nist.gov/nistpubs/FIPS/
           NIST.FIPS.204.pdf>.

[NC-HYBRID-AUTH]
           Becker, A., Guthrie, R., and M. J. Jenkins, "Non-Composite
           Hybrid Authentication in PKIX and Applications to Internet
           Protocols", Work in Progress, Internet-Draft, draft-
           becker-guthrie-noncomposite-hybrid-auth-00, 22 March 2022,
           <https://datatracker.ietf.org/doc/html/draft-becker-
           guthrie-noncomposite-hybrid-auth-00>.

[NIST_PQC_FAQ]
           NIST, "Post-Quantum Cryptography FAQs", 5 July 2022,
           <https://web.archive.org/web/20220705163944/
           https://csrc.nist.gov/Projects/ post-quantum-cryptography/
           faqs>.

[QRCSP]    Bernstein, D. J., "Quantifying risks in cryptographic
           selection processes", 24 November 2023,
           <https://cr.yp.to/papers/qrcsp-20231124.pdf>.

[RAINBOW]  "PQC Rainbow", <https://www.pqcrainbow.org/>.

[RSA]      Rivest, R. L., Shamir, A., and L. Adleman, "A Method for
           Obtaining Digital Signatures and Public-Key
           Cryptosystems", Communications of the ACM, vol. 21, no. 2,
           pp. 120-126, DOI 10.1145/359340.359342,
           <https://doi.org/10.1145/359340.359342>.

Acknowledgements 🫶

This document is based on the template used for [RFC9954] ✨.

We would like to acknowledge the following people in alphabetical order who have contributed to pushing this document forward, offered useful insights and perspectives, and/or stimulated work in the area: D.J. Bernstein, Scott Fluhrer, John Gray, Felix Günther, Serge Mister, Mike Ounsworth, Max Pala, Douglas Stebila, Falko Strenzke, and Brendan Zember 🌟. Iykyk, and y'all deserve all the flowers 💐.

Authors' Addresses 💌

Nina Bindel
SandboxAQ
Email: nina.bindel@sandboxaq.com


Britta Hale
Naval Postgraduate School
Email: britta.hale@nps.edu


Deirdre Connolly
SandboxAQ
Email: durumcrustulum@gmail.com


Florence Driscoll
UK National Cyber Security Centre
Email: flo.d@ncsc.gov.uk

📦 where this page comes from

ietf: rfc9955 2026-07
💖 girlified by claude-haiku-5-5 on 2026-10-19: a language model's rewrite of the original, under its terms