rfc9955.original   rfc9955.txt 
Network Working Group N. Bindel Internet Engineering Task Force (IETF) N. Bindel
Internet-Draft SandboxAQ Request for Comments: 9955 SandboxAQ
Intended status: Informational B. Hale Category: Informational B. Hale
Expires: 22 December 2025 Naval Postgraduate School ISSN: 2070-1721 Naval Postgraduate School
D. Connolly D. Connolly
SandboxAQ SandboxAQ
F. Driscoll F. Driscoll
UK National Cyber Security Centre UK National Cyber Security Centre
20 June 2025 April 2026
Hybrid signature spectrums Hybrid Signature Spectrums
draft-ietf-pquip-hybrid-signature-spectrums-07
Abstract Abstract
This document describes classification of design goals and security This document describes classification of design goals and security
considerations for hybrid digital signature schemes, including proof considerations for hybrid digital signature schemes, including proof
composability, non-separability of the component signatures given a composability, non-separability of the component signatures given a
hybrid signature, backwards/forwards compatibility, hybrid hybrid signature, backwards and forwards compatibility, hybrid
generality, and simultaneous verification. generality, and Simultaneous Verification (SV).
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Post-Quantum Use In
Protocols Working Group mailing list (pqc@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/pqc/.
Source for this draft and an issue tracker can be found at
https://github.com/dconnolly/draft-connolly-pquip-hybrid-signature-
spectrums.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9955.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 22 December 2025.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology
1.2. Motivation for Use of Hybrid Signature Schemes . . . . . 7 1.2. Motivation for Use of Hybrid Signature Schemes
1.2.1. Complexity . . . . . . . . . . . . . . . . . . . . . 7 1.2.1. Complexity
1.2.2. Time . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2.2. Time
1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3. Goals
1.3.1. Hybrid Authentication . . . . . . . . . . . . . . . . 9 1.3.1. Hybrid Authentication
1.3.2. Proof Composability . . . . . . . . . . . . . . . . . 10 1.3.2. Proof Composability
1.3.3. Weak Non-Separability . . . . . . . . . . . . . . . . 10 1.3.3. Weak Non-Separability
1.3.4. Strong Non-Separability . . . . . . . . . . . . . . . 11 1.3.4. Strong Non-Separability
1.3.5. Backwards/Forwards Compatibility . . . . . . . . . . 11 1.3.5. Backwards and Forwards Compatibility
1.3.6. Simultaneous Verification . . . . . . . . . . . . . . 12 1.3.6. Simultaneous Verification
1.3.7. Hybrid Generality . . . . . . . . . . . . . . . . . . 13 1.3.7. Hybrid Generality
1.3.8. High Performance . . . . . . . . . . . . . . . . . . 13 1.3.8. High Performance
1.3.9. High Space Efficiency . . . . . . . . . . . . . . . . 13 1.3.9. High Space Efficiency
1.3.10. Minimal Duplicate Information . . . . . . . . . . . . 13 1.3.10. Minimal Duplicate Information
2. Non-Separability Spectrum . . . . . . . . . . . . . . . . . . 13 2. Non-Separability Spectrum
3. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Artifacts
3.1. Artifacts vs. Separability . . . . . . . . . . . . . . . 16 3.1. Artifacts vs. Separability
3.2. Artifact Locations . . . . . . . . . . . . . . . . . . . 16 3.2. Artifact Locations
3.3. Artifact Location Comparison Example . . . . . . . . . . 17 3.3. Artifact Location Comparison Example
4. Need For Approval Spectrum . . . . . . . . . . . . . . . . . 21 4. Need for Approval Spectrum
5. EUF-CMA Challenges . . . . . . . . . . . . . . . . . . . . . 23 5. EUF-CMA Challenges
6. Discussion of Advantages/Disadvantages . . . . . . . . . . . 25 6. Discussion of Advantages and Disadvantages
6.1. Backwards Compatibility vs. SNS . . . . . . . . . . . . . 25 6.1. Backwards Compatibility vs. SNS
6.2. Backwards Compatibility vs. Hybrid Unforgeability . . . . 25 6.2. Backwards Compatibility vs. Hybrid Unforgeability
6.3. Simultaneous Verification vs. Low Need for Approval . . . 25 6.3. Simultaneous Verification vs. Low Need for Approval
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 9. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 26 9.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 26 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses
1. Introduction 1. Introduction
Plans to transition protocols to post-quantum cryptography sometimes Plans to transition protocols to post-quantum cryptography sometimes
focus on confidentiality, given the potential risk of store and focus on confidentiality, given the potential risk of store and
decrypt attacks, where data encrypted today using traditional decrypt attacks, where data encrypted today using traditional
algorithms could be decrypted in the future by an attacker with a algorithms could be decrypted in the future by an attacker with a
sufficiently powerful quantum computer, also known as a sufficiently powerful quantum computer, also known as a
Cryptographically-Relevant Quantum Computer (CRQC). Cryptographically Relevant Quantum Computer (CRQC).
It is important to also consider transitions to post-quantum It is important to also consider transitions to post-quantum
authentication; delaying such transitions creates risks. For authentication; delaying such transitions creates risks. For
example, attackers may be able to carry out quantum attacks against example, attackers may be able to carry out quantum attacks against
RSA-2048 [RSA] years before the public is aware of these RSA-2048 [RSA] years before the public is aware of these
capabilities. Furthermore, there are applications where algorithm capabilities. Furthermore, there are applications where algorithm
turn-over is complex or takes a long time. For example, root turnover is complex or takes a long time. For example, root
certificates are often valid for about 20 years or longer. There are certificates are often valid for about 20 years or longer. There are
also applications where future checks on past authenticity play a also applications where future checks on past authenticity play a
role, such as long-lived digital signatures on legal documents. role, such as long-lived digital signatures on legal documents.
Still, there have been successful attacks against algorithms using Still, there have been successful attacks against algorithms using
post-quantum cryptography, as well as implementations of such post-quantum cryptography, as well as implementations of such
algorithms. Sometimes an attack exploits implementation issues, such algorithms. Sometimes an attack exploits implementation issues, such
as [KYBERSLASH], which exploits timing variations, or [HQC_CVE] which as [KYBERSLASH], which exploits timing variations, or [HQC_CVE],
exploits implementation bugs. Sometimes an attack works for all which exploits implementation bugs. Sometimes an attack works for
implementations of the specified algorithm. Research has indicated all implementations of the specified algorithm. Research indicates
that implementation-independent attacks published in 2023 or earlier that implementation-independent attacks published in 2023 or earlier
had broken 48% of the proposals in Round 1 of the NIST Post-Quantum had broken 48% of the proposals in Round 1 of the NIST Post-Quantum
Cryptography Standardization Project, 25% of the proposals not broken Cryptography Standardization Project, 25% of the proposals not broken
in Round 1, and 36% of the proposals selected by NIST for Round 2 by the end of Round 1, and 36% of the proposals selected by NIST for
[QRCSP]. Round 2 [QRCSP].
Such cryptanalysis and security concerns are one reason to consider Such cryptanalysis and security concerns are one reason to consider
'hybrid' cryptographic algorithms, which combine both traditional and 'hybrid' cryptographic algorithms, which combine both traditional and
post-quantum (or more generally a combination of two or more) post-quantum (or more generally a combination of two or more)
algorithms. A core objective of hybrid algorithms is to protect algorithms. A core objective of hybrid algorithms is to protect
against quantum computers while at the same time making clear that against quantum computers while at the same time making clear that
the change is not reducing security. A premise of security of these the change is not reducing security. A security premise for these
algorithms being that if at least one of the two component algorithms algorithms is that if at least one of the two component algorithms of
of the hybrid scheme holds, the confidentiality or authenticity the hybrid scheme holds, the confidentiality or authenticity offered
offered by that scheme is maintained. It should be noted that the by that scheme is maintained. It should be noted that the word
word 'hybrid' has many uses, but this document uses 'hybrid' only in 'hybrid' has many uses, but this document uses 'hybrid' only in this
this algorithm sense. algorithm sense.
Whether or not hybridization is desired depends on the use case and Whether or not hybridization is desired depends on the use case and
security threat model. Users may recognize a need to start post- security threat model. Users may recognize a need to start post-
quantum transition, even while issues such as those described above quantum transition, even while issues such as those described above
are a concern. For this, hybridization can support transition. It are a concern. For this, hybridization can support transition. It
should be noted that hybridization is not necessary for all systems; should be noted that hybridization is not necessary for all systems;
recommendations on system types or analysis methods for such recommendations on system types or analysis methods for such
determination are out of scope of this document. For cases where determination are out of scope of this document. For cases where
hybridization is determined to be advantageous, a decision on how to hybridization is determined to be advantageous, a decision on how to
hybridize needs to be made. With many options available, this hybridize needs to be made. With many options available, this
document is intended to provide context on some of the trade-offs and document is intended to provide context on some of the trade-offs and
nuances to consider. nuances to consider.
Hybridization of digital signatures, where the hybrid signature may Hybridization of digital signatures, where the hybrid signature may
be expected to attest to both standard and post-quantum components, be expected to attest to both standard and post-quantum components,
is subtle to design and implement due to the potential separability is subtle to design and implement due to the potential separability
of the hybrid/dual signatures and the risk of downgrade/stripping of the hybrid/dual signatures and the risk of downgrade/stripping
attacks. There are also a range of requirements and properties that attacks. There are also a range of requirements and properties that
may be required from hybrid signatures, which will be discussed in may be required from hybrid signatures, which will be discussed in
this document. Some of these are mutually exclusive, which this document. Some of these are mutually exclusive, which
highlights the importance of considering use-case specific highlights the importance of considering use-case-specific
requirements. requirements.
This document focuses on explaining a spectrum of different hybrid This document focuses on explaining a spectrum of different hybrid
signature scheme design categories and different security goals for signature scheme design categories and different security goals for
them. It is intended as a resource for designers and implementers of them. It is intended as a resource for designers and implementers of
hybrid signature schemes to help them decide what properties they do hybrid signature schemes to help them decide what properties they do
and do not require from their use case. In scope limitations, it and do not require from their use case. In scope limitations, it
does not attempt to give concrete recommendations for any use case. does not attempt to give concrete recommendations for any use case.
It also intentionally does not propose concrete hybrid signature It also intentionally does not propose concrete hybrid signature
combiners or instantiations thereof. As with the data authenticity combiners or instantiations thereof. As with the data authenticity
guarantees provided by any digital signature, the security guarantees guarantees provided by any digital signature, the security guarantees
discussed in this document are reliant on correct provisioning and discussed in this document are reliant on correct provisioning and
management of the keys involved, e.g. entity authentication, key management of the keys involved, e.g., entity authentication, key
revocation etc. This document only considers scenarios with a single revocation, etc. This document only considers scenarios with a
signer and a single verifier, constructions with multiple signers or single signer and a single verifier; constructions with multiple
verifiers are out of scope. signers or verifiers are out of scope.
1.1. Terminology 1.1. Terminology
We follow existing Internet documents on hybrid terminology [RFC9794] We follow existing documents on hybrid terminology [RFC9794] and
and hybrid key encapsulation mechanisms (KEM) hybrid key encapsulation mechanisms (KEMs) [RFC9954] to enable
[I-D.ietf-tls-hybrid-design] to enable settling on a consistent settling on a consistent language. We will make clear when this is
language. We will make clear when this is not possible. In not possible. In particular, we follow the definitions of 'post-
particular, we follow the definition of 'post-quantum algorithm', quantum algorithm', 'traditional algorithm', and 'combiner'.
'traditional algorithms', and 'combiner'. Moreover, we use the Moreover, we use the definition of 'certificate' to mean 'public-key
definition of 'certificate' to mean 'public-key certificate' as certificate' as defined in [RFC4949].
defined in [RFC4949].
* Signature scheme: A signature scheme is defined via the following Signature scheme: A signature scheme is defined via the following
three algorithms: three algorithms:
- KeyGen() -> (pk, sk): A probabilistic key generation algorithm, KeyGen() -> (pk, sk):
which generates a public verifying key pk and a secret signing A probabilistic key generation algorithm, which generates a
key sk. public verifying key pk and a secret signing key sk.
- Sign(sk, m) -> (sig): A probabilistic signature generation, Sign(sk, m) -> (sig):
which takes as input a secret signing key sk and a message m, A probabilistic signature generation, which takes as input a
and outputs a signature sig. In this draft, the secret signing secret signing key sk and a message m, and outputs a signature
key sk is assumed to be implicit for notational simplicity, and sig. In this document, the secret signing key sk is assumed to
the following notation is used: Sign(m) -> (sig). If the be implicit for notational simplicity, and the following
message m is comprised of multiple fields, m1, m2, ..., mN, notation is used: Sign(m) -> (sig). If the message m is
this is notated Sign(m) = Sign (m1, m2, ... mN) -> (sig). comprised of multiple fields, m1, m2, ..., mN, this is notated
as Sign(m) = Sign (m1, m2, ... mN) -> (sig).
- Verify(pk, sig, m) -> b: A verification algorithm, which takes Verify(pk, sig, m) -> b:
as input a public verifying key pk, a signature sig and a A verification algorithm, which takes as input a public
message m, and outputs a bit b indicating accept (b=1) or verifying key pk, a signature sig, and a message m, and outputs
reject (b=0) of the signature for message m. a bit b indicating accept (b=1) or reject (b=0) of the
signature for the message m.
* Hybrid signature scheme: Following [RFC9794], we define a hybrid Hybrid signature scheme: Following [RFC9794], we define a hybrid
signature scheme to be "a multi-algorithm digital signature scheme signature scheme to be "a multi-algorithm digital signature scheme
made up of two or more component digital signature algorithms". made up of two or more component digital signature algorithms".
While it often makes sense for security purposes to require that While it often makes sense for security purposes to require that
the security of the component schemes is based on the hardness of the security of the component schemes is based on the hardness of
different cryptographic assumptions, in other cases hybrid schemes different cryptographic assumptions, in other cases, hybrid
might be motivated, e.g., by interoperability of variants on the schemes might be motivated, e.g., by interoperability of variants
same scheme and as such both component schemes are based on the on the same scheme, and as such, both component schemes are based
same hardness assumption (e.g., both post-quantum assumptions or on the same hardness assumption (e.g., both post-quantum
even both the same concrete assumption such as Ring LWE). We assumptions or even both the same concrete assumption, such as
allow this explicitly. This means in particular that in contrast Ring Learning With Errors (LWE)). We allow this explicitly. In
to [RFC9794], we will use the more general term 'hybrid signature particular, this means that in contrast to [RFC9794], we will use
scheme' instead of requiring one post-quantum and one traditional the more general term 'hybrid signature scheme' instead of
algorithm (i.e., PQ/T hybrid signature schemes) to allow also the requiring one post-quantum and one traditional algorithm (i.e.,
combination of several post-quantum algorithms. The term Post-Quantum Traditional (PQ/T) hybrid signature schemes) to allow
also the combination of several post-quantum algorithms. The term
'composite scheme' has sometimes been used as a synonym for 'composite scheme' has sometimes been used as a synonym for
'hybrid scheme'. This is different from [RFC9794] where the term 'hybrid scheme'. This is different from [RFC9794] where the term
is used as a specific instantiation of hybrid schemes such that is used as a specific instantiation of hybrid schemes such that
"where multiple cryptographic algorithms are combined to form a "where multiple cryptographic algorithms are combined to form a
single key or signature such that they can be treated as a single single key or signature such that they can be treated as a single
atomic object at the protocol level." To avoid confusing we will atomic object at the protocol level". To avoid confusion, we will
avoid the term 'composite scheme'. avoid the term 'composite scheme'.
* Hybrid signature: A hybrid signature is the output of the hybrid Hybrid signature: A hybrid signature is the output of the hybrid
signature scheme's signature generation. As synonyms we might use signature scheme's signature generation. As a synonym, we might
'dual signature'. For example, NIST defines a dual signature as use 'dual signature'. For example, NIST defines a dual signature
"two or more signatures on a common message" [NIST_PQC_FAQ]. For as "two or more signatures on a common message" [NIST_PQC_FAQ].
the same reason as above we will avoid using the term 'composite For the same reason as above, we will avoid using the term
signature' although it sometimes appears as a synonym for 'hybrid/ 'composite signature', although it sometimes appears as a synonym
dual signature'. for 'hybrid/dual signature'.
* Component (signature) scheme: Component signature schemes are the Component (signature) scheme: Component signature schemes are the
cryptographic algorithms contributing to the hybrid signature cryptographic algorithms contributing to the hybrid signature
scheme. This has a similar purpose as in [RFC9794]. 'Ingredient scheme. This has a similar purpose as in [RFC9794]. 'Ingredient
(signature) scheme' may be used as a synonym. (signature) scheme' may be used as a synonym.
* Next-generation algorithms: Following Next-generation algorithms: Following [RFC9954], we define next-
[I-D.ietf-tls-hybrid-design], we define next-generation algorithms generation algorithms to be "algorithms that are not yet widely
to be "algorithms which are not yet widely deployed but which may deployed but may eventually be widely deployed". Hybrid
eventually be widely deployed". Hybrid signatures are mostly signatures are mostly motivated by preparation for post-quantum
motivated by preparation for post-quantum transition or use in transition or use in long-term post-quantum deployment, hence the
long-term post-quantum deployment, hence the reference to post- reference to post-quantum algorithms in this document. However,
quantum algorithms through this document. However, the majority the majority of the discussion in this document applies equally
of the discussion in this document applies equally well to future well to future transitions to other next-generation algorithms.
transitions to other next-generation algorithms.
* Policy: Throughout this document we refer to 'policy' in the Policy: Throughout this document, we refer to 'policy' in the
context of e.g., a system policy requiring verification of two context of, e.g., a system policy requiring verification of two
signatures, an RFC description, guidance documentation, etc. signatures, an RFC description, guidance documentation, etc.
Similar terminology may include 'security configuration settings', Similar terminology may include 'security configuration settings'
or related phrasing. We treat these terms as equivalent for the or related phrasing. We treat these terms as equivalent for the
purposes of this document. purposes of this document.
* Artifact: An artifact is evidence of the sender's intent to Artifact: An artifact is evidence of the sender's intent to
hybridize a signature that remains even if a component signature hybridize a signature that remains even if a component signature
is removed. Artifacts can be e.g., at the algorithmic level is removed. Artifacts can be, e.g., at the algorithmic level
(e.g., within the digital signature), or at the protocol level (e.g., within the digital signature), at the protocol level (e.g.,
(e.g., within the certificate), or on the system policy level within the certificate), or on the system policy level (e.g.,
(e.g., within the message). Artifacts should be easily within the message). Artifacts should be easily identifiable by
identifiable by the receiver in the case of signature stripping. the receiver in the case of signature stripping.
* Stripping attack: A stripping attack refers to a case where an Stripping attack: A stripping attack refers to a case where an
adversary takes a message and hybrid signature pair and attempts adversary takes a message and hybrid signature pair and attempts
to submit (a potential modification of) the pair to a component to submit (a potential modification of) the pair to a component
algorithm verifier, meaning that the security is based only on the algorithm verifier, meaning that the security is based only on the
remaining component scheme. A common example of a stripping remaining component scheme. A common example of a stripping
attack includes a message and hybrid signature, comprised of attack includes a message and hybrid signature, comprised of
concatenated post-quantum and traditional signatures, where an concatenated post-quantum and traditional signatures, where an
adversary with a quantum computer simply removes the post-quantum adversary with a quantum computer simply removes the post-quantum
component signature and submits the (potentially changed) message component signature and submits the (potentially changed) message
and traditional component signature to a traditional verifier. and traditional component signature to a traditional verifier.
This could include an authentic traditional certificate authority This could include an authentic traditional certificate authority
signature on a certificate that was originaly hybrid-signed. An signature on a certificate that was originally hybrid-signed. An
attribute of this is that the an honest signer would attest to attribute of this is that an honest signer would attest to
generating the signature. Stripping attacks should not be generating the signature. Stripping attacks should not be
confused with component message forgery attacks. confused with component message forgery attacks.
* Component message forgery attacks: A forgery attack refers to a Component message forgery attacks: A forgery attack refers to a case
case where an adversary attempts to forge a (non-hybrid) signature where an adversary attempts to forge a (non-hybrid) signature on a
on a message using the public key associated with a component message using the public key associated with a component
algorithm. An common example of such an attack would be a quantum algorithm. A common example of such an attack would be a quantum
attacker compromising the key associated with a traditional attacker compromising the key associated with a traditional
component algorithm and forging a message and signature pair. component algorithm and forging a message and signature pair.
Message forgery attacks may be formalized with experiments such as Message forgery attacks may be formalized with experiments such as
existential unforgeability under chosen-message attack (EUF-CMA) the Existential Unforgeability under Chosen Message Attack (EUF-
[EUFCMA], while the difference introduced in component message CMA) [EUFCMA], while the difference introduced in component
forgery attacks is that the key is accepted for both hybrid and message forgery attacks is that the key is accepted for both
single algorithm use. Further discussions on this appear under hybrid and single algorithm use. Further discussion of this
Section 5. appears in Section 5.
1.2. Motivation for Use of Hybrid Signature Schemes 1.2. Motivation for Use of Hybrid Signature Schemes
Before diving into the design goals for hybrid digital signatures, it Before diving into the design goals for hybrid digital signatures, it
is worth taking a look at motivations for them. As many of the is worth taking a look at motivations for them. As many of the
arguments hold in general for hybrid algorithms, we again refer to arguments hold in general for hybrid algorithms, we again refer to
[I-D.ietf-tls-hybrid-design] that summarizes these well. In [RFC9954], which summarizes these well. In addition, we explicate
addition, we explicate the motivation for hybrid signatures here. the motivation for hybrid signatures here.
1.2.1. Complexity 1.2.1. Complexity
Next-generation algorithms and their underlying hardness assumptions Next-generation algorithms and their underlying hardness assumptions
are often more complex than traditional algorithms. For example, the are often more complex than traditional algorithms. For example, the
signature scheme ML-DSA [MLDSA] (also known as CRYSTALS-DILITHIUM) signature scheme Module-Lattice-Based Digital Signature Algorithm
follows the well-known Fiat-Shamir transform [FS] to construct the (ML-DSA) [MLDSA] (also known as CRYSTALS-DILITHIUM) follows the well-
signature scheme, but also relies on rejection sampling that is known known Fiat-Shamir transform [FS] to construct the signature scheme
to give cache side channel information (although this does not lead but also relies on rejection sampling that is known to give cache
to a known attack). Likewise, the signature scheme Falcon [FALCON] side channel information (although this does not lead to a known
uses complex sampling during signature generation. Furthermore, attack). Likewise, the signature scheme FALCON [FALCON] uses complex
attacks against the next-generation multivariate schemes Rainbow sampling during signature generation. Furthermore, attacks against
[RAINBOW] and GeMSS [GEMSS] might raise concerns for conservative the next-generation multivariate schemes Rainbow [RAINBOW] and Great
adopters of other algorithms, which could hinder adoption. Multivariate Short Signature (GeMSS) [GEMSS] might raise concerns for
conservative adopters of other algorithms, which could hinder
adoption.
As such, some next-generation algorithms carry a higher risk of As such, some next-generation algorithms carry a higher risk of
implementation mistakes and revision of parameters compared to implementation mistakes and revision of parameters compared to
traditional algorithms, such as RSA. RSA is a relatively simple traditional algorithms, such as RSA. RSA is a relatively simple
algorithm to understand and explain, yet during its existence and use algorithm to understand and explain, yet during its existence and
there have been multiple attacks and refinements, such as adding use, there have been multiple attacks and refinements, such as adding
requirements to how padding and keys are chosen, and implementation requirements to how padding and keys are chosen, and implementation
issues such as cross-protocol attacks (e.g., component algorithm issues, such as cross-protocol attacks (e.g., component algorithm
forgeries). Thus, even in a relatively simple algorithm subtleties forgeries). Thus, even in a relatively simple algorithm, subtleties
and caveats on implementation and use can arise over time. Given the and caveats on implementation and use can arise over time. Given the
complexity of next generation algorithms, the chance of such complexity of next-generation algorithms, the chance of such
discoveries and caveats needs to be taken into account. discoveries and caveats needs to be taken into account.
Of note, some next-generation algorithms have received considerable Of note, some next-generation algorithms have received considerable
analysis, for example, following attention gathered during the NIST analysis, for example, following attention gathered during the NIST
Post-Quantum Cryptography Standardization Process [NIST_PQC_FAQ]. Post-Quantum Cryptography Standardization Process [NIST_PQC_FAQ].
However, if and when further information on caveats and However, if and when further information on caveats and
implementation issues come to light, it is quite possible that implementation issues come to light, it is quite possible that
vulnerabilities will represent a weakening of security rather than a vulnerabilities will represent a weakening of security rather than a
full "break". Such weakening may also be offset if a hybrid approach full "break". Such weakening may also be offset if a hybrid approach
has been used. has been used.
1.2.2. Time 1.2.2. Time
In large systems, including national systems, space systems, large In large systems, including national systems, space systems, large
healthcare support systems, and critical infrastructure, acquisition healthcare support systems, and critical infrastructure, acquisition
and procurement time can be measured in years and algorithm and procurement time can be measured in years, and algorithm
replacement may be difficult or even practically impossible. Long- replacement may be difficult or even practically impossible. Long-
term commitment creates further urgency for immediate post-quantum term commitment creates further urgency for immediate post-quantum
algorithm selection, for example when generating root certificates algorithm selection, for example, when generating root certificates
with their long validity windows. Additionally, for some sectors, with their long validity windows. Additionally, for some sectors,
future checks on past authenticity plays a role (e.g., many legal, future checks on past authenticity plays a role (e.g., many legal,
financial, auditing, and governmental systems). This means there is financial, auditing, and governmental systems). This means there is
a need to transition some systems to post-quantum signature a need to transition some systems to post-quantum signature
algorithms imminently. However, as described above, there is a need algorithms imminently. However, as described above, there is a need
to remain aware of potential, hidden subtleties in next-generation to remain aware of potential, hidden subtleties in next-generation
algorithms' resistance to standard attacks, particularly in cases algorithms' resistance to standard attacks, particularly in cases
where it is difficult to replace algorithms. This combination of where it is difficult to replace algorithms. This combination of
time pressure and complexity drives some transition designs towards time pressure and complexity drives some transition designs towards
hybridization. hybridization.
1.3. Goals 1.3. Goals
There are various security and usability goals that can be achieved There are various security and usability goals that can be achieved
through hybridization. The following provides a summary of these through hybridization. The following provides a summary of these
goals, while also noting where goals are in conflict, i.e., that goals while also noting where goals are in conflict, i.e., that
achievement of one goal precludes another, such as backwards achievement of one goal precludes another, such as backwards
compatibility. compatibility.
1.3.1. Hybrid Authentication 1.3.1. Hybrid Authentication
One goal of hybrid signature schemes is security. As defined in One goal of hybrid signature schemes is security. As defined in
[RFC9794], ideally a hybrid signature scheme can achieve 'hybrid [RFC9794], ideally a hybrid signature scheme can achieve 'hybrid
authentication' which is the property that (cryptographic) authentication', which is the property that (cryptographic)
authentication is achieved by the hybrid signature scheme provided authentication is achieved by the hybrid signature scheme, provided
that a least one component signature algorithm remains 'secure'. that a least one component signature algorithm remains 'secure'.
There might be, however, other goals in competition with this one, There might be, however, other goals in competition with this one,
such as backward-compatibility - referring to the property where a such as backwards compatibility -- referring to the property where a
hybrid signature may be verified by only verifying one component hybrid signature may be verified by only verifying one component
signature (see description below). Hybrid authentication is an signature (see description below). Hybrid authentication is an
umbrella term that encompasses more specific concepts of hybrid umbrella term that encompasses more specific concepts of hybrid
signature security, such as 'hybrid unforgeability' described next. signature security, such as 'hybrid unforgeability' described next.
1.3.1.1. Hybrid Unforgeability 1.3.1.1. Hybrid Unforgeability
Hybrid unforgeability is a specific type of hybrid authentication, Hybrid unforgeability is a specific type of hybrid authentication,
where the security assumption for the scheme, e.g. EUF-CMA, is where the security assumption for the scheme (e.g., EUF-CMA) is
maintained as long as at least one of the component schemes maintains maintained as long as at least one of the component schemes maintains
that security assumption. We call this notion 'hybrid that security assumption. We call this notion 'hybrid
unforgeability'; it is a specific type of hybrid authentication. For unforgeability'; it is a specific type of hybrid authentication. For
example, the concatenation combiner in [HYBRIDSIG] is 'hybrid example, the concatenation combiner in [HYBRIDSIG] is 'hybrid
unforgeable'. As mentioned above, this might be incompatible with unforgeable'. As mentioned above, this might be incompatible with
backward-compatibility, where the EUF-CMA security of the hybrid backwards compatibility, where the EUF-CMA security of the hybrid
signature relies solely on the security of one of the component signature relies solely on the security of one of the component
schemes instead of relying on both, e.g., the dual message combiner schemes instead of relying on both, e.g., the dual message combiner
using nesting in [HYBRIDSIG]. For more details, we refer to our using nesting in [HYBRIDSIG]. For more details, refer to the
discussion below. discussion below.
Use cases where a hybrid scheme is used with, e.g., EUF-CMA security Use cases where a hybrid scheme is used with, e.g., EUF-CMA security
assumed for only one component scheme generally use hybrid techniques assumed for only one component scheme generally use hybrid techniques
for their 'functional transition' pathway support. For example, for their 'functional transition' pathway support. For example,
hybrid signatures may be used as a transition step for gradual post- hybrid signatures may be used as a transition step for gradual post-
quantum adoption, while ensuring interoperability when a system quantum adoption while ensuring interoperability when a system
includes both verifiers that only support traditional signatures and includes both verifiers that only support traditional signatures and
verifiers that have been upgraded to support post-quantum signatures. verifiers that have been upgraded to support post-quantum signatures.
In contrast, use cases where a hybrid scheme is used with e.g., EUF- In contrast, use cases where a hybrid scheme is used with, e.g., EUF-
CMA security assumed for both component schemes without CMA security assumed for both component schemes without
prioritisation between them can use hybrid techniques for both prioritization between them can use hybrid techniques for both
functional transition and security transition (i.e., a transition to functional transition and security transition (i.e., a transition to
ensure security even if it may not be known which algorithm should be ensure security even if it may not be known which algorithm should be
relied upon). relied upon).
1.3.2. Proof Composability 1.3.2. Proof Composability
Under proof composability, the component algorithms are combined in Under proof composability, the component algorithms are combined in
such a way that it is possible to prove a security reduction from the such a way that it is possible to prove a security reduction from the
security properties of a hybrid signature scheme to the properties of security properties of a hybrid signature scheme to the properties of
the respective component signature schemes and, potentially, other the respective component signature schemes and, potentially, other
skipping to change at page 10, line 22 skipping to change at line 425
etc. Otherwise, an entirely new proof of security is required, and etc. Otherwise, an entirely new proof of security is required, and
there is a lack of assurance that the combination builds on the there is a lack of assurance that the combination builds on the
standardization processes and analysis performed to date on component standardization processes and analysis performed to date on component
algorithms. The resulting hybrid signature would be, in effect, an algorithms. The resulting hybrid signature would be, in effect, an
entirely new algorithm of its own. The more the component signature entirely new algorithm of its own. The more the component signature
schemes are entangled, the more likely it is that an entirely new schemes are entangled, the more likely it is that an entirely new
proof is required, thus not meeting proof composability. proof is required, thus not meeting proof composability.
1.3.3. Weak Non-Separability 1.3.3. Weak Non-Separability
Non-Separability was one of the earliest properties of hybrid digital Non-separability was one of the earliest properties of hybrid digital
signatures to be discussed [HYBRIDSIG]. It was defined as the signatures to be discussed [HYBRIDSIG]. It was defined as the
guarantee that an adversary cannot simply "remove" one of the guarantee that an adversary cannot simply "remove" one of the
component signatures without evidence left behind. For example, component signatures without evidence left behind. For example,
there are artifacts that a carefully designed verifier may be able to there are artifacts that a carefully designed verifier may be able to
identify, or that are identifiable in later audits. This was later identify or that are identifiable in later audits. This was later
termed Weak Non-Separability (WNS) [HYBRIDSIGDESIGN]. Note that WNS termed Weak Non-Separability (WNS) [HYBRIDSIGDESIGN]. Note that WNS
does not restrict an adversary from potentially creating a valid does not restrict an adversary from potentially creating a valid
component digital signature from a hybrid one (a signature stripping component digital signature from a hybrid one (a signature stripping
attack), but rather implies that such a digital signature will attack) but rather implies that such a digital signature will contain
contain artifacts of the separation. Thus, authentication that is artifacts of the separation. Thus, authentication that is normally
normally assured under correct verification of digital signature(s), assured under correct verification of digital signature(s) is now
is now potentially also reliant on further investigation on the potentially also reliant on further investigation on the receiver
receiver side that may extend well beyond traditional signature side that may extend well beyond traditional signature verification
verification behavior. For instance, this can intuitively be seen in behavior. For instance, this can intuitively be seen in cases of a
cases of a message containing a context note on hybrid message containing a context note on hybrid authentication that is
authentication, that is then signed by all component algorithms/the then signed by all component algorithms/the hybrid signature scheme.
hybrid signature scheme. If an adversary removes one component If an adversary removes one component signature but not the other,
signature but not the other, then artifacts in the message itself then artifacts in the message itself point to the possible existence
point to the possible existence of hybrid signature such as a label of a hybrid signature such as a label stating "this message must be
stating, "this message must be hybrid signed". This might be a hybrid-signed". This might be a countermeasure against stripping
counter measure against stripping attacks if the verifier expects a attacks if the verifier expects a hybrid signature scheme to have
hybrid signature scheme to have this property. However, it places this property. However, it places the responsibility of signature
the responsibility of signature validity not only on the correct validity not only on the correct format of the message, as in a
format of the message, as in a traditional signature security traditional signature security guarantee, but the precise content
guarantee, but the precise content thereof. thereof.
1.3.4. Strong Non-Separability 1.3.4. Strong Non-Separability
Strong Non-Separability (SNS) is a stronger notion of WNS, introduced Strong Non-Separability (SNS) is a stronger notion of WNS, which is
in [HYBRIDSIGDESIGN]. SNS guarantees that an adversary cannot take introduced in [HYBRIDSIGDESIGN]. SNS guarantees that an adversary
as input a hybrid signature (and message) and output a valid cannot take a hybrid signature (and message) as input and output a
component signature (and potentially different message) that will valid component signature (and potentially different message) that
verify correctly. In other words, separation of the hybrid signature will verify correctly. In other words, separation of the hybrid
into component signatures implies that the component signature will signature into component signatures implies that the component
fail verification (of the component signature scheme) entirely. signature will fail verification (of the component signature scheme)
Therefore, authentication is provided by the sender to the receiver entirely. Therefore, authentication is provided by the sender to the
through correct verification of the digital signature(s), as in receiver through correct verification of the digital signature(s), as
traditional signature security experiments. It is not dependent on in traditional signature security experiments. It is not dependent
other components, such as message content checking, or protocol level on other components, such as message content checking, or protocol-
aspects, such as public key provenance. As an illustrative example level aspects, such as public key provenance. As an illustrative
distinguishing WNS from SNS, consider the case of component example distinguishing WNS from SNS, consider the case of component
algorithms Sigma_1.Sign and Sigma_2.Sign where the hybrid signature algorithms Sigma_1.Sign and Sigma_2.Sign where the hybrid signature
is computed as a concatenation (sig_1, sig_2), where sig_1 = is computed as a concatenation (sig_1, sig_2), where sig_1 =
Sigma_1.Sign(hybridAlgID, m) and sig_2 = Sigma_2.Sign(hybridAlgID, Sigma_1.Sign(hybridAlgID, m) and sig_2 = Sigma_2.Sign(hybridAlgID,
m). In this case, a new message m' = (hybridAlgID, m) along with 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 signature sig_1 and Sigma_1.pk, with the hybrid artifact embedded in
the message instead of the signature, could be correctly verified. the message instead of the signature, could be correctly verified.
The separation would be identifiable through further investigation, The separation would be identifiable through further investigation,
but the signature verification itself would not fail. Thus, this but the signature verification itself would not fail. Thus, this
case shows WNS (assuming the verification algorithm is defined case shows WNS (assuming the verification algorithm is defined
accordingly) but not SNS. accordingly) but not SNS.
Some work [I-D.ietf-lamps-pq-composite-sigs] has looked at reliance Some work [COMP-MLDSA] has looked at reliance on the public key
on the public key certificate chains to explicitly define hybrid use certificate chains to explicitly define hybrid use of the public key,
of the public key. Namely, that Sigma_1.pk cannot be used without namely that Sigma_1.pk cannot be used without Sigma_2.pk. This
Sigma_2.pk. This implies pushing the hybrid artifacts into the implies pushing the hybrid artifacts into the protocol and system
protocol and system level and a dependency on the security of other level and a dependency on the security of other verification
verification algorithms (namely those in the certificate chain). algorithms (namely those in the certificate chain). This further
This further requires that security analysis of a hybrid digital requires that security analysis of a hybrid digital signature
signature requires analysis of the key provenance, i.e., not simply requires analysis of the key provenance, i.e., not simply that a
that a valid public key is used but how its hybridization and hybrid valid public key is used but how its hybridization and hybrid
artifacts have been managed throughout the entire chain. External artifacts have been managed throughout the entire chain. External
dependencies such as this may imply hybrid artifacts lie outside the dependencies such as this may imply hybrid artifacts lie outside the
scope of the signature algorithm itself. SNS may potentially be scope of the signature algorithm itself. SNS may potentially be
achievable based on dependencies at the system level. achievable based on dependencies at the system level.
1.3.5. Backwards/Forwards Compatibility 1.3.5. Backwards and Forwards Compatibility
Backwards compatibility refers to the property where a hybrid Backwards compatibility refers to the property where a hybrid
signature may be verified by only verifying one component signature, signature may be verified by only verifying one component signature,
allowing the scheme to be used by legacy receivers. In general, this allowing the scheme to be used by legacy receivers. In general, this
means verifying the traditional component signature scheme, means verifying the traditional component signature scheme,
potentially ignoring the post-quantum signature entirely. This potentially ignoring the post-quantum signature entirely. This
provides an option to transition sender systems to post-quantum provides an option to transition sender systems to post-quantum
algorithms while still supporting select legacy receivers. Notably, algorithms while still supporting select legacy receivers. Notably,
this is a verification property; the sender has provided a hybrid this is a verification property; the sender has provided a hybrid
digital signature, but the verifier is allowed, due to internal digital signature, but the verifier is allowed, due to internal
policy and/or implementation, to only verify one component signature. policy and/or implementation, to only verify one component signature.
Forwards compatibility has also been a consideration in hybrid Forwards compatibility has also been a consideration in hybrid
proposals [I-D.becker-guthrie-noncomposite-hybrid-auth]. Forward proposals [NC-HYBRID-AUTH]. Forwards compatibility assumes that
compatibility assumes that hybrid signature schemes will be used for hybrid signature schemes will be used for some time but that
some time, but that eventually all systems will transition to use eventually all systems will transition to use only one (particularly,
only one (particularly, only one post-quantum) algorithm. As this is only one post-quantum) algorithm. As this is very similar to
very similar to backwards compatibility, it also may imply backwards compatibility, it also may imply separability of a hybrid
separability of a hybrid algorithm; however, it could also simply algorithm; however, it could also simply imply capability to support
imply capability to support separate component signatures. Thus, the separate component signatures. Thus, the key distinction between
key distinction between backwards and forwards compatibility is that backwards and forwards compatibility is that backwards compatibility
backwards compatibility may be needed for legacy systems that cannot may be needed for legacy systems that cannot use and/or process
use and/or process hybrid or post-quantum signatures, whereas in hybrid or post-quantum signatures, whereas in forwards compatibility,
forwards compatibility the system has those capabilities and can the system has those capabilities and can choose what to support
choose what to support (e.g., for efficiency reasons). (e.g., for efficiency reasons).
As noted in [I-D.ietf-tls-hybrid-design], ideally, forward/backward Ideally, backwards and forwards compatibility is achieved using
compatibility is achieved using redundant information as little as redundant information as little as possible, as noted in [RFC9954].
possible.
1.3.6. Simultaneous Verification 1.3.6. Simultaneous Verification
Simultaneous Verification (SV) builds on SNS and was first introduced Simultaneous Verification (SV) builds on SNS and was first introduced
in [HYBRIDSIGDESIGN]. SV requires that not only is the entire hybrid in [HYBRIDSIGDESIGN]. SV requires that not only is the entire hybrid
signature (e.g., all component signature elements) needed to achieve signature (e.g., all component signature elements) needed to achieve
a successful verification present in the signature presented for a successful verification present in the signature presented for
verification, but also that verification of both component algorithms verification but also that verification of both component algorithms
occurs roughly simultaneously. Namely, "missing" information needs occurs roughly simultaneously. Namely, "missing" information needs
to be computed by the verifier so that a normally functioning to be computed by the verifier so that a normally functioning
verification algorithm cannot "quit" the verification process before verification algorithm cannot "quit" the verification process before
the hybrid signature elements attesting for both component algorithms the hybrid signature elements attesting for both component algorithms
are verified. This may additionally cover some error-injection and are verified. This may additionally cover some error-injection and
similar attacks, where an adversary attempts to make an otherwise similar attacks, where an adversary attempts to make an otherwise
honest verifier skip component algorithm verification. SV mimics honest verifier skip component algorithm verification. SV mimics
traditional digital signatures guarantees, essentially ensuring that traditional digital signatures guarantees, essentially ensuring that
the hybrid digital signature behaves as a single algorithm vs. two the hybrid digital signature behaves as a single algorithm vs. two
separate component stages. Alternatively phrased, under an SV separate component stages. Alternatively phrased, under an SV
guarantee it is not possible for an otherwise honest verifier to guarantee, it is not possible for an otherwise honest verifier to
initiate termination of the hybrid verification upon successful initiate termination of the hybrid verification upon successful
verification of one component algorithm without also knowing if the verification of one component algorithm without also knowing if the
other component succeeded. Note that SV does not prevent dishonest other component succeeded. Note that SV does not prevent dishonest
verification, such as if a verifier maliciously implements a verification, such as if a verifier maliciously implements a
customized verification algorithm that is designed with intention to customized verification algorithm that is designed with intention to
subvert the hybrid verification process or skips signature subvert the hybrid verification process or skips signature
verification altogether. verification altogether.
1.3.7. Hybrid Generality 1.3.7. Hybrid Generality
Hybrid generality means that a general signature combiner is defined, Hybrid generality means that a general signature combiner is defined
based on inherent and common structures of component digital based on inherent and common structures of component digital
signatures "categories." For instance, since multiple signature signatures "categories". For instance, since multiple signature
schemes use a Fiat-Shamir Transform, a hybrid scheme based on the schemes use a Fiat-Shamir transform, a hybrid scheme based on the
transform can be made that is generalizable to all such signatures. transform can be made that is generalizable to all such signatures.
Such generality can also result in simplified constructions whereas Such generality can also result in simplified constructions, whereas
more tailored hybrid variants might be more efficient in terms of more tailored hybrid variants might be more efficient in terms of
sizes and performance. sizes and performance.
1.3.8. High Performance 1.3.8. High Performance
Similarly to performance goals noted for hybridization of other Similar to performance goals noted for hybridization of other
cryptographic components [I-D.ietf-tls-hybrid-design] hybrid cryptographic components [RFC9954], hybrid signature constructions
signature constructions are expected to be as performant as possible. are expected to be as performant as possible. For most hybrid
For most hybrid signatures this means that the computation time signatures, this means that the computation time should only
should only minimally exceed the sum of the component signature minimally exceed the sum of the component signature computation time.
computation time. It is noted that performance of any variety may It is noted that performance of any variety may come at the cost of
come at the cost of other properties, such as hybrid generality. other properties, such as hybrid generality.
1.3.9. High Space Efficiency 1.3.9. High Space Efficiency
Similarly to space considerations in [I-D.ietf-tls-hybrid-design], Similar to space considerations in [RFC9954], hybrid signature
hybrid signature constructions are expected to be as space performant constructions are expected to be as space performant as possible.
as possible. This includes messages (as they might increase if This includes messages (as they might increase if artifacts are
artifacts are used), public keys, and the hybrid signature. For the used), public keys, and the hybrid signature. For the hybrid
hybrid signature, size should no more than minimally exceed the signature, size should no more than minimally exceed the signature
signature size of the two component signatures. In some cases, it size of the two component signatures. In some cases, it may be
may be possible for a hybrid signature to be smaller than the possible for a hybrid signature to be smaller than the concatenation
concatenation of the two component signatures. of the two component signatures.
1.3.10. Minimal Duplicate Information 1.3.10. Minimal Duplicate Information
Duplicated information should be avoided when possible, as a general Duplicated information should be avoided when possible, as a general
point of efficiency. This might include repeated information in point of efficiency. This might include repeated information in
hybrid certificates or in the communication of component certificates hybrid certificates or in the communication of component certificates
in additional to hybrid certificates (for example, to achieve in addition to hybrid certificates (for example, to achieve backwards
backwards/forwards-compatibility) or sending multiple public keys or and forwards compatibility) or sending multiple public keys or
signatures of the same component algorithm. signatures of the same component algorithm.
2. Non-Separability Spectrum 2. Non-Separability Spectrum
Non-separability is not a singular definition but rather is a scale, Non-separability is not a singular definition but rather is a scale
representing degrees of separability hardness, visualized in representing degrees of separability hardness, visualized in
Figure 1. Figure 1.
|-----------------------------------------------------------------------------| | ----------------------------------------------------------|
|**No Non-Separability** | *No Non-Separability*
| no artifacts exist |
|-----------------------------------------------------------------------------| | No artifacts exist.
|**Weak Non-Separability** | ----------------------------------------------------------|
| artifacts exist in the message, signature, system, application, or protocol | *Weak Non-Separability*
| ----------------------------------------------------------------------------| |
|**Strong Non-Separability** | Artifacts exist in the message, signature, system,
| artifacts exist in hybrid signature | application, or protocol.
| ----------------------------------------------------------------------------| | ----------------------------------------------------------|
|**Strong Non-Separability w/ Simultaneous Verification** | *Strong Non-Separability*
| artifacts exist in hybrid signature and verification or failure of both |
| components occurs simultaneously | 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.
| ----------------------------------------------------------|
▼
Figure 1: Spectrum of non-separability from weakest to strongest. Figure 1: Spectrum of Non-Separability from Weakest to Strongest
At one end of the spectrum are schemes in which one of the component At one end of the spectrum are schemes in which one of the component
signatures can be stripped away with the verifier not being able to signatures can be stripped away with the verifier not being able to
detect the change during verification. An example of this includes detect the change during verification. An example of this includes
simple concatenation of signatures without any artifacts used. simple concatenation of signatures without any artifacts used.
Nested signatures (where a message is signed by one component Nested signatures (where a message is signed by one component
algorithm and then the message-signature combination is signed by the algorithm and then the message-signature combination is signed by the
second component algorithm) may also fall into this category, second component algorithm) may also fall into this category,
dependent on whether the inner or outer signature is stripped off dependent on whether the inner or outer signature is stripped off
without any artifacts remaining. without any artifacts remaining.
Next on the spectrum are weakly non-separable signatures. Under Weak Next on the spectrum are weakly non-separable signatures. Under Weak
Non-Separability, if one of the component signatures of a hybrid is Non-Separability, if one of the component signatures of a hybrid is
removed artifacts of the hybrid will remain (in the message, removed, artifacts of the hybrid will remain (in the message, in the
signature, or at the protocol level, etc.). This may enable the signature, at the protocol level, etc.). This may enable the
verifier to detect if a component signature is stripped away from a verifier to detect if a component signature is stripped away from a
hybrid signature, but that detectability depends highly on the type hybrid signature, but that detectability depends highly on the type
of artifact and permissions. For instance, if a message contains a of artifact and permissions. For instance, if a message contains a
label artifact "This message must be signed with a hybrid signature" label artifact "This message must be signed with a hybrid signature",
then the system must be allowed to analyze the message contents for then the system must be allowed to analyze the message contents for
possible artifacts. Whether a hybrid signature offers (Weak/Strong) possible artifacts. Whether a hybrid signature offers (Weak/Strong)
Non-Separability might also depend on the implementation and policy Non-Separability might also depend on the implementation and policy
of the protocol or application the hybrid signature is used in on the of the protocol or application the hybrid signature is used in on the
verifier side. Such policies may be further ambiguous to the sender, verifier side. Such policies may be further ambiguous to the sender,
meaning that the type of authenticity offered to the receiver is meaning that the type of authenticity offered to the receiver is
unclear. In another example, under nested signatures the verifier unclear. In another example, under nested signatures, the verifier
could be tricked into interpreting a new message as the message/inner could be tricked into interpreting a new message as the message/inner
signature combination and verify only the outer signature. In this signature combination and verify only the outer signature. In this
case, the inner signature is an artifact. case, the inner signature is an artifact.
Third on the scale is the Strong Non-Separability notion, in which Third on the scale is the Strong Non-Separability notion, in which
separability detection is dependent on artifacts in the signature separability detection is dependent on artifacts in the signature
itself. Unlike in Weak Non-Separability, where artifacts may be in itself. Unlike in Weak Non-Separability, where artifacts may be in
the actual message, the certificate, or in other non-signature the actual message, the certificate, or other non-signature
components, this notion more closely ties to traditional algorithm components, this notion more closely ties to traditional algorithm
security notions (such as EUF-CMA) where security is dependent on the security notions (such as EUF-CMA) where security is dependent on the
internal construct of the signature algorithm and its verification. internal construct of the signature algorithm and its verification.
In this type, the verifier can detect artifacts on an algorithmic In this type, the verifier can detect artifacts on an algorithmic
level during verification. For example, the signature itself may level during verification. For example, the signature itself may
encode the information that a hybrid signature scheme is used. encode the information that a hybrid signature scheme is used.
Examples of this type may be found in [HYBRIDSIGDESIGN]. Examples of this type may be found in [HYBRIDSIGDESIGN].
For schemes achieving the most demanding security notion, Strong Non- For schemes achieving the most demanding security notion, Strong Non-
Separability with Simultaneous Verification, verification succeeds Separability with Simultaneous Verification, verification succeeds
only when both of the component signatures are present and the only when both of the component signatures are present and the
verifier has verified both signatures. Moreover, no information is verifier has verified both signatures. Moreover, no information is
leaked to the receiver during the verification process on the leaked to the receiver during the verification process on the
possible validity of the component signatures until both verify (or possible validity of the component signatures until both verify (or
verification failure may or may not be attributable to a specific verification failure may or may not be attributable to a specific
component algorithm). This construct most closely mirrors component algorithm). This construct most closely mirrors
traditional digital signatures where, assuming that the verifier does traditional digital signatures where, assuming that the verifier does
verify a signature at all, the result is either a positive verify a signature at all, the result is either a positive
verification of the full signature or a failure if the signature is verification of the full signature or a failure if the signature is
not valid. For fused hybrid signatures, a full signature implies the not valid. For fused hybrid signatures, a full signature implies the
fusion of both component algorithms, and therefore this type of fusion of both component algorithms; therefore, this type of
construction has the potential to achieve the strongest non- construction has the potential to achieve the strongest non-
separability notion which ensures an all-or-nothing approach to separability notion, which ensures an all-or-nothing approach to
verification, regardless of adversarial action. Examples of verification, regardless of adversarial action. Examples of
algorithms providing this type of security can be found in algorithms providing this type of security can be found in
[HYBRIDSIGDESIGN]. [HYBRIDSIGDESIGN].
3. Artifacts 3. Artifacts
Hybridization benefits from the presence of artifacts as evidence of Hybridization benefits from the presence of artifacts as evidence of
the sender's intent to decrease the risk of successful stripping the sender's intent to decrease the risk of successful stripping
attacks. This, however, depends strongly on where such evidence attacks. This, however, depends strongly on where such evidence
resides (e.g., in the message, the signature, or somewhere on the resides (e.g., in the message, in the signature, or somewhere on the
protocol level instead of at the algorithmic level). Even commonly protocol level instead of at the algorithmic level). Even commonly
discussed hybrid approaches, such as concatenation, are not discussed hybrid approaches, such as concatenation, are not
inherently tied to one type of security (e.g., WNS or SNS). This can inherently tied to one type of security (e.g., WNS or SNS). This can
lead to ambiguities when comparing different approaches and lead to ambiguities when comparing different approaches and
assumptions about security or lack thereof. Thus, in this section we assumptions about security or lack thereof. Thus, in this section,
cover artifact locations and also walk through a high-level we cover artifact locations and also walk through a high-level
comparison of a few hybrid categories to show how artifact location comparison of a few hybrid categories to show how artifact location
can differ within a given approach. Artifact location is tied to can differ within a given approach. Artifact location is tied to
non-separability notions above; thus the selection of a given non-separability notions as described above; thus, the selection of a
security guarantee and general hybrid approach must also include given security guarantee and general hybrid approach must also
finer grained selection of artifact placement. include a finer-grained selection of artifact placement.
3.1. Artifacts vs. Separability 3.1. Artifacts vs. Separability
Note that non-separability is a security notion of the signature Note that non-separability is a security notion of the signature
scheme and not directly related to artifacts – artifacts may be used scheme and not directly related to artifacts -- however, artifacts
for detection of separation, however. For instance, under strong may be used for detection of separation. For instance, under strong
non-separability, the scheme would fail verification if separation non-separability, the scheme would fail verification if separation
occurs, while for weak non-separability some artifacts exist if occurs, while for weak non-separability, some artifacts exist if
separation occurs but verification would not necessarily fail. The separation occurs but verification would not necessarily fail. The
verifier could indeed ignore the artifact, hence the scheme achieving verifier could indeed ignore the artifact, resulting in the scheme
only weak non-separability and not strong non-separability. It is achieving only weak non-separability and not strong non-separability.
rather that an artifact exists that could be identified if an It is rather that an artifact exists that could be identified if an
investigation occurred, etc. Under weak non-separability, detection investigation occurred, etc. Under weak non-separability, detection
of separation may depend on non-cryptographic configurations or other of separation may depend on non-cryptographic configurations or other
dependencies. Also, strong non-separability and weak non- dependencies. Also, strong non-separability and weak non-
separability are properties of the signature scheme – artifacts are separability are properties of the signature scheme -- artifacts are
not necessarily in the signature and may appear in the signed not necessarily in the signature and may appear in the signed
message, the certificate, the protocol, or policy (hence them not message, certificate, protocol, or policy (hence them not necessarily
necessarily being related to the strong non-separability and weak being related to the strong non-separability and weak non-
non-separablity security notions). Artifacts may still be useful separability security notions). Artifacts may still be useful
(albeit dependent on system configurations) even if separable (albeit dependent on system configurations) even if separable
signatures are used. signatures are used.
3.2. Artifact Locations 3.2. Artifact Locations
There are a variety of artifact locations possible, ranging from There are a variety of artifact locations possible, ranging from
within the message to the signature algorithm to the protocol level within the message to the signature algorithm to the protocol level
and even into policy, as shown in Table 1. For example, one artifact and even into policy, as shown in Table 1. For example, one artifact
location could be in the message to be signed, e.g., containing a location could be in the message to be signed, e.g., containing a
label artifact. Depending on the hybrid type, it might be possible label artifact. Depending on the hybrid type, it might be possible
to strip this away. For example, a quantum attacker could strip away to strip this away. For example, a quantum attacker could strip away
the post-quantum signature of a concatenated dual signature, and, the post-quantum signature of a concatenated dual signature, and,
being able to forge the traditional signature, remove the label being able to forge the traditional signature, it could remove the
artifact from the message as well. So, for many applications and label artifact from the message as well. So, for many applications
threat models, adding an artifact in the message might be and threat models, adding an artifact in the message might be
insufficient under stripping attacks. Another artifact location insufficient under stripping attacks. Another artifact location
could be in the public key certificates as described in could be in the public key certificates as described in [COMP-MLDSA].
[I-D.ietf-lamps-pq-composite-sigs]. In such a case, the artifacts In such a case, the artifacts are still present even if a stripping
are still present even if a stripping attack occurs. In yet another attack occurs. In yet another case, artifacts may be present through
case, artifacts may be present through the fused hybrid method, thus the fused hybrid method, thus making them part of the signature at
making them part of the signature at the algorithmic level. Note the algorithmic level. Note that in this latter case, it is not
that in this latter case, it is not possible for an adversary to possible for an adversary to strip one of the component signatures or
strip one of the component signatures or use a component of the use a component of the hybrid to create a forgery for a component
hybrid to create a forgery for a component algorithm. Such algorithm. Such signatures provide SNS. Consequently, this also
signatures provide SNS. This consequently also implies that the implies that the artifacts of hybridization are absolute in that
artifacts of hybridization are absolute in that verification failure verification failure would occur if an adversary tries to remove
would occur if an adversary tries to remove them. them.
Eventual security analysis may be a consideration in choosing between Eventual security analysis may be a consideration in choosing between
levels. For example, if the security of the hybrid scheme is levels. For example, if the security of the hybrid scheme is
dependent on system policy, then cryptographic analysis must dependent on system policy, then cryptographic analysis must
necessarily be reliant on specific policies, and it may not be necessarily be reliant on specific policies, and it may not be
possible to describe a scheme's security in a standalone sense. In possible to describe a scheme's security in a standalone sense. In
this case, it is necessary to consider the configuration of a this case, it is necessary to consider the configuration of a
particular implementation or use to assess security, which could particular implementation or use to assess security, which could
increase the risk of unknown and unanticipated vulnerabilities, increase the risk of unknown and unanticipated vulnerabilities,
regardless of the algorithms in use. regardless of the algorithms in use.
+=============================================+===========+ +========================================+===========+
| Location of Artifacts of Hybrid Intent | Level | | Location of Artifacts of Hybrid Intent | Level |
+=============================================+===========+ +========================================+===========+
| Signature | Algorithm | | Signature | Algorithm |
+---------------------------------------------+-----------+ +----------------------------------------+-----------+
| Certificate | Protocol | | Certificate | Protocol |
+---------------------------------------------+-----------+ +----------------------------------------+-----------+
| Algorithm agreement / negotiation | Protocol | | Algorithm agreement / negotiation | Protocol |
+---------------------------------------------+-----------+ +----------------------------------------+-----------+
| Message | Policy | | Message | Policy |
+---------------------------------------------+-----------+ +----------------------------------------+-----------+
Table 1: Artifact placement levels Table 1: Artifact Placement Levels
3.3. Artifact Location Comparison Example 3.3. Artifact Location Comparison Example
Here we provide a high-level example of how artifacts can appear in Here we provide a high-level example of how artifacts can appear in
different locations even within a single, common approach. We look different locations even within a single, common approach. We look
at the following categories of approaches: concatenation, nesting, at the following categories of approaches: concatenation, nesting,
and fusion. This is to illustrate that a given approach does not and fusion. This is to illustrate that a given approach does not
inherently imply a specific non-separability notion and that there inherently imply a specific non-separability notion and that there
are subtleties to the selection decision, since hybrid artifacts are are subtleties to the selection decision, since hybrid artifacts are
related to non-separability guarantees. Additionally, this related to non-separability guarantees. Additionally, this
comparison highlights how artifacts placement can be identical in two comparison highlights how artifact placement can be identical in two
different hybrid approaches. different hybrid approaches.
We briefly summarize the hybrid approach categories (concatenation, We briefly summarize the hybrid approach categories (concatenation,
nesting, and fusion) for clarity in description, before showing how nesting, and fusion) for clarity in description before showing how
each one may have artifacts in different locations in Table 2. each one may have artifacts in different locations in Table 2.
* Concatenation: variants of hybridization where, for component * Concatenation: Variants of hybridization where, for component
algorithms Sigma_1.Sign and Sigma_2.Sign, the hybrid signature is algorithms Sigma_1.Sign and Sigma_2.Sign, the hybrid signature is
calculated as a concatenation (sig_1, sig_2) such that sig_1 = calculated as a concatenation (sig_1, sig_2) such that sig_1 =
Sigma_1.Sign(hybridAlgID || m) and sig_2 = Sigma_1.Sign(hybridAlgID || m) and sig_2 =
Sigma_2.Sign(hybridAlgID || m). Sigma_2.Sign(hybridAlgID || m).
* Nesting: variants of hybridization where for component algorithms * Nesting: Variants of hybridization where, for component algorithms
Sigma_1.Sign and Sigma_2.Sign, the hybrid signature is calculated Sigma_1.Sign and Sigma_2.Sign, the hybrid signature is calculated
in a layered approach as (sig_1, sig_2) such that, e.g., sig_1 = in a layered approach as (sig_1, sig_2) such that, e.g., sig_1 =
Sigma_1.Sign(hybridAlgID || m) and sig_2 = Sigma_1.Sign(hybridAlgID || m) and sig_2 =
Sigma_2.Sign(hybridAlgID || (m || sig_1)). Sigma_2.Sign(hybridAlgID || (m || sig_1)).
* Fused hybrid: variants of hybridization where for component * Fused hybrid: Variants of hybridization, where for component
algorithms Sigma_1.Sign and Sigma_2.Sign, the hybrid signature is algorithms Sigma_1.Sign and Sigma_2.Sign, the hybrid signature is
calculated to generate a single hybrid signature sig_h that cannot calculated to generate a single hybrid signature sig_h that cannot
be cleanly separated to form one or more valid component be cleanly separated to form one or more valid component
constructs. For example, if both signature schemes are signatures constructs. For example, if both signature schemes are
schemes constructed through the Fiat-Shamir transform, the constructed through the Fiat-Shamir transform, the component
component signatures would include responses r_1 and r_2 and signatures would include responses r_1 and r_2 and challenges c_1
challenges c_1 and c_2, where c_1 and c_2 are hashes computed over and c_2, where c_1 and c_2 are hashes computed over the respective
the respective commitments comm_1 and comm_2 (and the message). A commitments comm_1 and comm_2 (and the message). A fused hybrid
fused hybrid signature could consist of the component responses, signature could consist of the component responses r_1 and r_2 and
r_1 and r_2 and a challenge c that is computed as a hash over both a challenge c that is computed as a hash over both commitments,
commitments, i.e., c = Hash((comm_1 || comm_2) || Hash2(message)). i.e., c = Hash((comm_1 || comm_2) || Hash2(message)). As such, c
As such, c does not belong to either of the component signatures does not belong to either of the component signatures but rather
but rather both, meaning that the signatures are 'entangled'. both, meaning that the signatures are 'entangled'.
+====+=======================+=============================+ +====+=======================+=============================+
| # | Location of artifacts | Category | | # | Location of Artifacts | Category |
| | of hybrid intent | | | | of Hybrid Intent | |
+====+=======================+=============================+ +====+=======================+=============================+
| | | *Concatenated* | | | | *Concatenated* |
+----+-----------------------+-----------------------------+ +----+-----------------------+=============================+
| 1 | None | No label in message, public | | 1 | None | No label in message, public |
| | | keys are in separate certs | | | | keys are in separate certs |
+----+-----------------------+-----------------------------+ +----+-----------------------+-----------------------------+
| 2 | In message | Label in message, public | | 2 | In message | Label in message, public |
| | | keys are in separate certs | | | | keys are in separate certs |
+----+-----------------------+-----------------------------+ +----+-----------------------+-----------------------------+
| 3 | In cert | No label in message, public | | 3 | In cert | No label in message, public |
| | | keys are in combined cert | | | | keys are in combined cert |
+----+-----------------------+-----------------------------+ +----+-----------------------+-----------------------------+
| 4 | In message and cert | Label in message, public | | 4 | In message and cert | Label in message, public |
| | | keys are in combined cert | | | | keys are in combined cert |
+----+-----------------------+-----------------------------+ +----+-----------------------+=============================+
| | | *Nested* | | | | *Nested* |
+----+-----------------------+-----------------------------+ +----+-----------------------+=============================+
| 5 | In message | Label in message, public | | 5 | In message | Label in message, public |
| | | keys are in separate certs | | | | keys are in separate certs |
+----+-----------------------+-----------------------------+ +----+-----------------------+-----------------------------+
| 6 | In cert | No label in message, public | | 6 | In cert | No label in message, public |
| | | keys are in combined cert | | | | keys are in combined cert |
+----+-----------------------+-----------------------------+ +----+-----------------------+-----------------------------+
| 7 | In message and cert | Label in message, public | | 7 | In message and cert | Label in message, public |
| | | keys are in combined cert | | | | keys are in combined cert |
+----+-----------------------+-----------------------------+ +----+-----------------------+=============================+
| | | *Fused* | | | | *Fused* |
+----+-----------------------+-----------------------------+ +----+-----------------------+=============================+
| 8 | In signature | Public keys are in separate | | 8 | In signature | Public keys are in separate |
| | | certs | | | | certs |
+----+-----------------------+-----------------------------+ +----+-----------------------+-----------------------------+
| 9 | In signature and | Label in message, public | | 9 | In signature and | Label in message, public |
| | message | keys are in separate certs | | | message | keys are in separate certs |
+----+-----------------------+-----------------------------+ +----+-----------------------+-----------------------------+
| 10 | In signature and cert | Public keys are in combined | | 10 | In signature and cert | Public keys are in combined |
| | | cert | | | | cert |
+----+-----------------------+-----------------------------+ +----+-----------------------+-----------------------------+
| 11 | In signature and | Label in message, public | | 11 | In signature and | Label in message, public |
| | message and cert | keys are in combined cert | | | message and cert | keys are in combined cert |
+----+-----------------------+-----------------------------+ +----+-----------------------+-----------------------------+
Table 2: Artifact locations depending on the hybrid Table 2: Artifact Locations Depending on the Hybrid
signature type Signature Type
As can be seen, while concatenation may appear to refer to a single As can be seen, while concatenation may appear to refer to a single
type of combiner, there are in fact several possible artifact type of combiner, there are in fact several possible artifact
locations depending on implementation choices. Artifacts help to locations depending on implementation choices. Artifacts help to
support detection in the case of stripping attacks, which means that support detection in the case of stripping attacks, which means that
different artifact locations imply different overall system different artifact locations imply different overall system
implementation considerations to be able to achieve such detection. implementation considerations to be able to achieve such detection.
Case 1 provides the weakest guarantees of hybrid identification, as Case 1 provides the weakest guarantees of hybrid identification, as
there are no prescribed artifacts and therefore non-separability is there are no prescribed artifacts and therefore non-separability is
not achieved. However, as can be seen, this does not imply that not achieved. However, as can be seen, this does not imply that
every implementation using concatenation fails to achieve non- every implementation using concatenation fails to achieve non-
separability. Thus, it is advisable for implementors to be separability. Thus, it is advisable for implementers to be
transparent about artifact locations. transparent about artifact locations.
In cases 2 and 5 the artifacts lie within the message. This is In cases 2 and 5, the artifacts lie within the message. This is
notable as the authenticity of the message relies on the validity of notable as the authenticity of the message relies on the validity of
the signature, and the artifact location means that the signature in the signature, and the artifact location means that the signature in
turn relies on the authentic content of the message (the artifact turn relies on the authentic content of the message (the artifact
label). This creates a risk of circular dependency. Alternative label). This creates a risk of circular dependency. Alternative
approaches such as cases 3, 4, 6 and 7 solve this circular dependency approaches, such as cases 3, 4, 6, and 7, solve this circular
by provisioning keys in a combined certificate. dependency by provisioning keys in a combined certificate.
Another observation from this comparison is that artifact locations Another observation from this comparison is that artifact locations
may be similar among some approaches. For instance, case 3 and case may be similar among some approaches. For instance, cases 3 and 6
6 both contain artifacts in the certificate. Naturally these both contain artifacts in the certificate. Naturally, these are
examples are high-level and further specification on concrete schemes high-level examples and further specification on concrete schemes in
in the categories are needed before prescribing non-separability the categories are needed before prescribing non-separability
guarantees to each, but this does indicate how there could be a guarantees to each, but this does indicate how there could be a
strong similarity between such guarantees. Such comparisons allow strong similarity between such guarantees. Such comparisons allow
for a systematic decision process, where security is compared and for a systematic decision process, where security is compared and
identified and, if schemes are similar in the desired security goal, identified, and if schemes are similar in the desired security goal,
then decisions between schemes can be based on performance and then decisions between schemes can be based on performance and
implementation ease. implementation ease.
A final observation that this type of comparison provides is how A final observation that this type of comparison provides is how
various combiners may change the security analysis assumptions in a various combiners may change the security analysis assumptions in a
system. For instance, cases 3, 4, 6, and 7 all push artifacts - and system. For instance, cases 3, 4, 6, and 7 all push artifacts -- and
therefore the signature validity - into the certificate chain. therefore the signature validity -- into the certificate chain.
Naturally the entire chain must then also use a similar combiner if a Naturally, the entire chain must then also use a similar combiner if
straightforward security argument is to be made. Other cases, such a straightforward security argument is to be made. Other cases, such
as 8, 9, 10, and 11 put artifacts within the signature itself, as 8, 9, 10, and 11, put artifacts within the signature itself,
meaning that these bear the closest resemblance to traditional meaning that these bear the closest resemblance to traditional
schemes where message authenticity is dependent on signature schemes where message authenticity is dependent on signature
validity. validity.
4. Need For Approval Spectrum 4. Need for Approval Spectrum
In practice, use of hybrid digital signatures relies on standards In practice, use of hybrid digital signatures relies on standards
where applicable. This is particularly relevant in the cases where where applicable. This is particularly relevant in the cases where
use of FIPS (Federal Information Processing Standard) approved use of FIPS-approved software modules is required but applies equally
software modules is required, but applies equally to any guidance or to any guidance or policy direction that specifies that at least one
policy direction that specifies that at least one component algorithm component algorithm of the hybrid has passed some certification type
of the hybrid has passed some certification type while not specifying while not specifying requirements on the other component. NIST
requirements on the other component. NIST provides the following provides the following guidance in [NIST_PQC_FAQ] (emphasis added):
guidance (emphasis added),
Assume that in a [hybrid] signature, _one signature is generated | Assume that in a [hybrid] signature, _one signature is generated
with a NIST-approved signature scheme as specified in FIPS 186, | with a NIST-approved signature scheme as specified in FIPS 186,
while another signature(s) can be generated using different | while another signature(s) can be generated using different
schemes_, e.g., ones that are not currently specified in NIST | schemes_, e.g., ones that are not currently specified in NIST
standards..._hybrid signatures can be accommodated by current | standards ... _[hybrid] signatures can be accommodated by current
standards in FIPS mode, as defined in FIPS 140, provided at least | standards in "FIPS mode", as defined in FIPS 140, provided at
one of the component methods is a properly implemented, NIST- | least one of the component methods is a properly implemented,
approved signature algorithm_. For the purposes of FIPS 140 | NIST-approved signature algorithm_. For the purposes of FIPS 140
validation, any signature that is generated by a non-approved | validation, any signature that is generated by a non-approved
component scheme would not be considered a security function, | component scheme would not be considered a security function,
since the NIST-approved component is regarded as assuring the | since the NIST-approved component is regarded as assuring the
validity of the hybrid signature. [NIST_PQC_FAQ] | validity of the [hybrid] signature.
This draft does not define a formal interpretation of the NIST This document does not define a formal interpretation of the NIST
statement; however, we use it as motivation to highlight some points statement; however, we use it as motivation to highlight some points
that implementors of hybrids may wish to consider when following any that implementers of hybrids may wish to consider when following any
guidance documents that specify that 1) the signature scheme for one guidance documents that specify that 1) the signature scheme for one
of the component algorithms must be approved and 2) the said of the component algorithms must be approved and 2) the said
algorithm must be a well implemented or a certified implementation. algorithm must be a well-implemented or certified implementation.
This type of need for approval (i.e., a requirement that an This type of need for approval (i.e., a requirement that an
implementor is looking to follow regarding approval or certification implementer is looking to follow regarding approval or certification
of the software module implementation of hybrid or its component of the software module implementation of a hybrid or its component
algorithms) can drive some logistical decisios on what types of algorithms) can drive some logistical decisions on what types of
hybrids an implementor should consider. hybrids an implementer should consider.
In this respect, there is a scale of approval that developers may In this respect, there is a scale of approval that developers may
consider as to whether they are using at least one approved component consider as to whether they are using at least one approved component
algorithm implementation (1-out-of-n approved software module), or algorithm implementation (1-out-of-n approved software module) or
whether every component algorithm implementation is individually whether every component algorithm implementation is individually
approved (all approved software module). approved (all approved software module).
We provide a scale for the different nuances of approval of the We provide a scale for the different nuances of approval of the
hybrid combiners, where "approval" means that a software hybrid combiners, where "approval" means that a software
implementation of a component algorithm can be used unmodified for implementation of a component algorithm can be used unmodified for
creation of the hybrid signature. This may be related to whether a creation of the hybrid signature. This may be related to whether a
hybrid combiner is likely to need dedicated certification. hybrid combiner is likely to need dedicated certification.
| ---------------------------------------------------------------------------------| | ---------------------------------------------------------|
| **New Algorithm** | *New Algorithm*
| New signature scheme based on a selection of hardness assumptions |
| Separate approval needed | New signature scheme based on a selection of hardness
| ---------------------------------------------------------------------------------| | assumptions.
| **No Approved Software Module** |
| Hybrid combiner supports security analysis that can be reduced to | Separate approval needed.
| approved component algorithms, potentially changing the component implementations | ---------------------------------------------------------|
| Uncertainty about whether separate approval is needed | *No Approved Software Module*
| ---------------------------------------------------------------------------------| |
| **1-out-of-n Approved Software Module** | Hybrid combiner supports security analysis that can be
| Combiner supports one component algorithm and implementation in a black-box way | reduced to approved component algorithms, potentially
| but potentially changes the other component algorithm implementation(s) | changing the component implementations.
| No new approval needed if the black-box component (implementation) is approved |
| ---------------------------------------------------------------------------------| | Uncertainty about whether separate approval is needed.
| **All Approved Software Modules** | ---------------------------------------------------------|
| Hybrid combiner acts as a wrapper, fully independent of the component | *1-out-of-n Approved Software Module*
| signature scheme implementations |
| No new approval needed if at least one component implementation is approved | 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.
| ---------------------------------------------------------|
▼
Figure 2: Generality / Need for Approval spectrum Figure 2: Generality / Need for Approval Spectrum
The first listed "combiner" would be a new construction with a The first listed "combiner" would be a new construction with a
security reduction to different hardness assumptions but not security reduction to different hardness assumptions but not
necessarily to approved (or even existing) signature schemes. Such a necessarily to approved (or even existing) signature schemes. Such a
new, singular algorithm relies on both traditional and next-gen new, singular algorithm relies on both traditional and next-
principles. generation principles.
Next, is a combiner that might take inspiration from existing/ Next is a combiner that might take inspiration from existing/approved
approved signature schemes such that its security can be reduced to signature schemes such that its security can be reduced to the
the security of the approved algorithms. The combiner may, however, security of the approved algorithms. The combiner may, however,
alter the implementations. As such it is uncertain whether new alter the implementations. As such, it is uncertain whether new
approval would be needed as it might depend on the combiner and approval would be needed as it might depend on the combiner and
changes. Such a case may potentially imply a distinction between a changes. Such a case may potentially imply a distinction between a
need for fresh approval of the algorithm(s) and approval of the need for fresh approval of the algorithm(s) and approval of the
implementation(s). implementation(s).
The 1-out-of-n combiner uses at least one approved algorithm The 1-out-of-n combiner uses at least one approved algorithm
implementation in a black-box way (i.e., without modification to the implementation in a black-box way (i.e., without modification to the
software module implementaton for that algorithm). It may software module implementation for that algorithm). It may
potentially change the specifics of the other component algorithm potentially change the specifics of the other component algorithm
implementations. If the premise is that no new approval is needed so implementations. If the premise is that no new approval is needed so
long as at least one component is approved, then this is likely long as at least one component is approved, then this is likely
considered sufficient. considered sufficient.
In an all-approved combiner, every algorithm implementation is used In an all-approved combiner, every algorithm implementation is used
in a black-box way. A concatenation combiner is a simple example in a black-box way. A concatenation combiner is a simple example
(where a signature is valid if all component signatures are valid). (where a signature is valid if all component signatures are valid).
Thus, as all algorithm implementations are approved, a requirement Thus, as all algorithm implementations are approved, a requirement
that at least one of hybrid component algorithms is approved would be that at least one of hybrid component algorithms is approved would be
satisfied. satisfied.
5. EUF-CMA Challenges 5. EUF-CMA Challenges
Unforgeability properties for hybrid signature schemes are more Unforgeability properties for hybrid signature schemes are more
nuanced than for single-algorithm schemes. nuanced than for single-algorithm schemes.
Under the traditional EUF-CMA security assumption, an adversary can Under the traditional EUF-CMA security assumption, an adversary
request signatures for messages of their choosing and succeeds if requests signatures for messages of their choosing and succeeds if
they are able to produce a valid signature for a message that was not they are able to produce a valid signature for a message that was not
part of an earlier request. EUF-CMA can be seen as applying to the part of an earlier request. EUF-CMA can be seen as applying to the
hybrid signature scheme in the same way as single-algorithm schemes. hybrid signature scheme in the same way as single-algorithm schemes.
Namely, the most straightforward extension of the traditional EUF-CMA Namely, the most straightforward extension of the traditional EUF-CMA
security game would be that an adversary can request hybrid security game would be that an adversary requests hybrid signatures
signatures for messages of their choosing and succeeds if they are for messages of their choosing and succeeds if they are able to
able to produce a valid hybrid signature for a message that was not produce a valid hybrid signature for a message that was not part of
part of an earlier request. However, this has several layers of an earlier request. However, this has several layers of nuance under
nuance under a hybrid construct. a hybrid construct.
Consider, for example, a simplistic hybrid approach using Consider, for example, a simplistic hybrid approach using
concatenated component algorithms. If the hybrid signature is concatenated component algorithms. If the hybrid signature is
stripped, such that a single component signature is submitted to a stripped, such that a single component signature is submitted to a
verification algorithm for that component along with the message that verification algorithm for that component along with the message that
was signed by the hybrid, the result would be an EUF-CMA forgery for was signed by the hybrid, the result would be an EUF-CMA forgery for
the component signature. This is because as the component signing the component signature. This is because as the component signing
algorithm was not previously called for the message - the hybrid algorithm was not previously called for the message, the hybrid
signing algorithm was used to generate the signature. This is an signing algorithm was used to generate the signature. This is an
example of a component algorithm forgery, a.k.a. a case of cross- example of a component algorithm forgery, a.k.a. a case of cross-
algorithm attack or cross-protocol attack. algorithm attack or cross-protocol attack.
The component algorithm forgery verifier target does not need to be The component algorithm forgery verifier target does not need to be
the intended recipient of the hybrid-signed message and may even be the intended recipient of the hybrid-signed message and may even be
in an entirely different system. This vulnerability is particularly in an entirely different system. This vulnerability is particularly
an issue among concatenated or nested hybrid signature schemes where an issue among concatenated or nested hybrid signature schemes where
individual component verification could be possible. It should be individual component verification could be possible. It should be
noted that policy enforcement of a hybrid verification does not noted that policy enforcement of a hybrid verification does not
mitigate the issue on the intended message recipient: the component mitigate the issue on the intended message recipient: The component
forgery could occur on any system that accepts the component keys. forgery could occur on any system that accepts the component keys.
Thus, if EUF-CMA security for hybrids is considered to be informally Thus, if EUF-CMA security for hybrids is informally defined in the
defined in the straightfoward way as that an adversary can request straightforward way as that an adversary requests hybrid signatures
hybrid signatures for messages of their choosing and succeeds if they for messages of their choosing and succeeds if they are able to
are able to produce a valid hybrid signature for a message that was produce a valid hybrid signature for a message that was not part of
not part of an earlier request, implicit requirements must hold in an earlier request, implicit requirements must hold in order to avoid
order to avoid real-world implications. Namely, either component real-world implications. Namely, either component algorithm
algorithm forgeries, a.k.a. cross-protocol attacks, must be out of forgeries, a.k.a. cross-protocol attacks, must be out of scope for
scope for the use case or the hybrid signature choice must be the use case or the hybrid signature choice must be strongly non-
strongly non-separable. Otherwise, component algorithm forgeries, separable. Otherwise, component algorithm forgeries, which can be
which can be seen as a type of cross-protocol attack, affect the type seen as a type of cross-protocol attack, affect the type of EUF-CMA
of EUF-CMA properties offered and are a practical consideration that properties offered and are a practical consideration that system
system designers and managers should be aware of when selecting among designers and managers should be aware of when selecting among hybrid
hybrid approaches for their use case. approaches for their use case.
There are a couple approaches to alleviating this issue, as noted There are a couple approaches to alleviating this issue, as noted
above. One is on restricting key reuse. As described in above. One is on restricting key reuse. As described in
[I-D.ietf-lamps-pq-composite-sigs], prohibiting hybrid algorithm and [COMP-MLDSA], prohibiting hybrid algorithm and component algorithm
component algorithm signers and verifiers from using the same keys signers and verifiers from using the same keys can help ensure that a
can help ensure that a component verifier cannot be tricked into component verifier cannot be tricked into verifying the hybrid
verifying the hybrid signature. This would effectively put component signature. This would effectively put component forgeries out of
forgeries out of scope for a use case. One means for restricting key scope for a use case. One means for restricting key reuse is through
reuse is through allowed key use descriptions in certificates. While allowed key use descriptions in certificates. While prohibiting key
prohibiting key reuse reduces the risk of such component forgeries, reuse reduces the risk of such component forgeries, and is the
and is the mitigation described in mitigation described in [COMP-MLDSA], it is still a policy
[I-D.ietf-lamps-pq-composite-sigs], it is still a policy requirement requirement and not a cryptographic assurance. Component forgery
and not a cryptographic assurance. Component forgery attacks may be attacks may be possible if the policy is not followed or is followed
possible if the policy is not followed or is followed inconsistently inconsistently across all entities that might verify signatures using
across all entities that might verify signatures using those keys. those keys. This needs to be accounted for in any security analysis.
This needs to be accounted for in any security analysis. Since Since cryptographic provable security modeling has not historically
cryptographic provable security modeling has not historically
accounted for key reuse in this way, it should not be assumed that accounted for key reuse in this way, it should not be assumed that
systems with existing analyses are robust to this issue. systems with existing analyses are robust to this issue.
The other approach noted for alleviating the component forgery risk The other approach noted for alleviating the component forgery risk
is through hybrid signature selection of a scheme that provides is through hybrid signature selection of a scheme that provides
strong non-separability. Under this approach, the hybrid signature strong non-separability. Under this approach, the hybrid signature
cannot be separated into component algorithm signatures that will cannot be separated into component algorithm signatures that will
verify correctly, thereby preventing the signature separation verify correctly, thereby preventing the signature separation
required for the component forgery attack to be successful. required for the component forgery attack to be successful.
It should be noted that weak non-separability is insufficient for It should be noted that weak non-separability is insufficient for
mitigating risks of component forgeries. As noted in mitigating risks of component forgeries. As noted in Section 9.3 of
[I-D.ietf-lamps-pq-composite-sigs], Sect. 11.3, in cases of hybrid [COMP-MLDSA], in cases of hybrid algorithm selection that provide
algorithm selection that provide only weak non-separability, key only weak non-separability, key reuse should be avoided, as mentioned
reuse should be avoided, as mentioned above, to mitigate risks of above, to mitigate risks of introducing EUF-CMA vulnerabilities for
introducing EUF-CMA vulnerabilities for component algorithms. component algorithms.
6. Discussion of Advantages/Disadvantages 6. Discussion of Advantages and Disadvantages
The design (and hence, security guarantees) of hybrid signature The design (and hence security guarantees) of hybrid signature
schemes depend heavily on the properties needed for the application schemes depend heavily on the properties needed for the application
or protocol using hybrid signatures. It seems that not all goals can or protocol using hybrid signatures. It seems that not all goals can
be achieved simultaneously as exemplified below. be achieved simultaneously as exemplified below.
6.1. Backwards Compatibility vs. SNS 6.1. Backwards Compatibility vs. SNS
There is an inherent mutual exclusion between backwards compatibility There is an inherent mutual exclusion between backwards compatibility
and SNS. While WNS allows for a valid separation under leftover and SNS. While WNS allows for a valid separation under leftover
artifacts, SNS will ensure verification failure if a receiver artifacts, SNS will ensure verification failure if a receiver
attempts separation. attempts separation.
6.2. Backwards Compatibility vs. Hybrid Unforgeability 6.2. Backwards Compatibility vs. Hybrid Unforgeability
Similarly, there is an inherent mutual exclusion between backwards Similarly, there is an inherent mutual exclusion between backwards
compatibility, when acted upon, and hybrid unforgeability as briefly compatibility, when acted upon, and hybrid unforgeability, as briefly
mentioned above. Since the goal of backwards compatibility is mentioned above. Since the goal of backwards compatibility is
usually to allow legacy systems without any software change to be usually to allow legacy systems without any software change to be
able to process hybrid signatures, all differences between the legacy able to process hybrid signatures, all differences between the legacy
signature format and the hybrid signature format must be allowed to signature format and the hybrid signature format must be allowed to
be ignored, including skipping verification of signatures additional be ignored, including skipping verification of signatures additional
to the classical signature. As such, if a system does skip a to the classical signature. As such, if a system does skip a
component signature, security does not rely on the security of all component signature, security does not rely on the security of all
component signatures. Note that this mutual exclusion occurs at the component signatures. Note that this mutual exclusion occurs at the
verification stage, as a hybrid signature that is verified by a verification stage, as a hybrid signature that is verified by a
system that can process both component schemes can provide hybrid system that can process both component schemes can provide hybrid
unforgeability even if another (legacy) system, processing the same unforgeability even if another (legacy) system, processing the same
hybrid signature, loses that property. hybrid signature, loses that property.
6.3. Simultaneous Verification vs. Low Need for Approval 6.3. Simultaneous Verification vs. Low Need for Approval
Hybrid algorithms that achieve simultaneous verification tend to fuse Hybrid algorithms that achieve simultaneous verification tend to fuse
(or 'entangle') the verification of component algorithms such that (or 'entangle') the verification of component algorithms such that
verification operations from the different component schemes depend verification operations from the different component schemes depend
on each other in some way. Consequently, there may be a natural on each other in some way. Consequently, there may be a natural
connection between achieving simultaneous verification and a higher connection between achieving simultaneous verification and a higher
need-for-approval. As a contrasting example, NIST accommodate need for approval. As a contrasting example, NIST accommodates
concatenation of a FIPS approved signature and another (potentially concatenation of a FIPS-approved signature and another (potentially
non-FIPS approved) signature without any artifacts in FIPS 140 non-FIPS approved) signature without any artifacts in FIPS 140
validation [NIST_PQC_FAQ], however as the component signatures are validation [NIST_PQC_FAQ]; however, as the component signatures are
verified separately it is not possible to enforce 'simultaneous verified separately, it is not possible to enforce 'simultaneous
verification'. verification'.
7. Security Considerations 7. Security Considerations
This document discusses digital signature constructions that may be This document discusses digital signature constructions that may be
used in security protocols. It is an informational document and does used in security protocols. It is an Informational document and does
not directly affect any other Internet-Draft. The security not directly affect any other documents. The security considerations
considerations for any specific implementation or incorporation of a for any specific implementation or incorporation of a hybrid scheme
hybrid scheme should be discussed in the relevant specification should be discussed in the relevant specification documents.
documents.
8. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
9. Acknowledgements 9. References
This document is based on the template of
[I-D.ietf-tls-hybrid-design].
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, Felix Günther, John Gray, Serge
Mister, Max Pala, Mike Ounsworth, Douglas Stebila, Falko Strenzke,
Brendan Zember
10. References
10.1. Normative References
[I-D.ietf-tls-hybrid-design] 9.1. Normative References
Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key
exchange in TLS 1.3", Work in Progress, Internet-Draft,
draft-ietf-tls-hybrid-design-13, 17 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
hybrid-design-13>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/rfc/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for [RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for
Post-Quantum Traditional Hybrid Schemes", RFC 9794, Post-Quantum Traditional Hybrid Schemes", RFC 9794,
DOI 10.17487/RFC9794, June 2025, DOI 10.17487/RFC9794, June 2025,
<https://www.rfc-editor.org/rfc/rfc9794>. <https://www.rfc-editor.org/info/rfc9794>.
10.2. Informative References [RFC9954] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid Key
Exchange in TLS 1.3", RFC 9954, DOI 10.17487/RFC9954,
April 2026, <https://www.rfc-editor.org/info/rfc9954>.
[EUFCMA] Green, M., "EUF-CMA and SUF-CMA", n.d., 9.2. Informative References
[COMP-MLDSA]
Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S.
Fluhrer, "Composite ML-DSA for use in X.509 Public Key
Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-lamps-pq-composite-sigs-15, 24 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-15>.
[EUFCMA] Green, M., "EUF-CMA and SUF-CMA",
<https://blog.cryptographyengineering.com/euf-cma-and-suf- <https://blog.cryptographyengineering.com/euf-cma-and-suf-
cma/>. cma/>.
[FALCON] "FALCON: Fast-Fourier Lattice-based Compact Signatures [FALCON] Fouque, P., Hoffstein, J., Kirchner, P., Lyubashevsky, V.,
over NTRU", n.d., <https://falcon-sign.info/falcon.pdf>. 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 [FS] Fiat, A. and A. Shamir, "How To Prove Yourself: Practical
Solutions to Identification and Signature Problems", 1986, 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>. <https://doi.org/10.1007%2F3-540-47721-7_12>.
[GEMSS] "GeMSS: A Great Multivariate Short Signature", 15 April [GEMSS] "GeMSS: A Great Multivariate Short Signature", 15 April
2020, <https://www-polsys.lip6.fr/Links/NIST/ 2020, <https://www-polsys.lip6.fr/Links/NIST/
GeMSS_specification_round2_V2.pdf>. GeMSS_specification_round2_V2.pdf>.
[HQC_CVE] "Correctness error in HQC decapsulation", 6 December 2024, [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>. <https://nvd.nist.gov/vuln/detail/CVE-2024-54137>.
[HYBRIDSIG] [HYBRIDSIG]
Bindel, N., Herath, U., McKague, M., and D. Stebila, Bindel, N., Herath, U., McKague, M., and D. Stebila,
"Transitioning to a Quantum-Resistant Public Key "Transitioning to a Quantum-Resistant Public Key
Infrastructure", May 2017, Infrastructure", Cryptology ePrint Archive, Paper
<https://eprint.iacr.org/2017/460>. 2017/460, May 2017, <https://eprint.iacr.org/2017/460>.
[HYBRIDSIGDESIGN] [HYBRIDSIGDESIGN]
Bindel, N. and B. Hale, "A Note on Hybrid Signature Bindel, N. and B. Hale, "A Note on Hybrid Signature
Schemes", March 2023, <https://eprint.iacr.org/2023/423>. Schemes", Cryptology ePrint Archive, Paper 2023/423, March
2023, <https://eprint.iacr.org/2023/423>.
[I-D.becker-guthrie-noncomposite-hybrid-auth] [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 Becker, A., Guthrie, R., and M. J. Jenkins, "Non-Composite
Hybrid Authentication in PKIX and Applications to Internet Hybrid Authentication in PKIX and Applications to Internet
Protocols", Work in Progress, Internet-Draft, draft- Protocols", Work in Progress, Internet-Draft, draft-
becker-guthrie-noncomposite-hybrid-auth-00, 22 March 2022, becker-guthrie-noncomposite-hybrid-auth-00, 22 March 2022,
<https://datatracker.ietf.org/doc/html/draft-becker- <https://datatracker.ietf.org/doc/html/draft-becker-
guthrie-noncomposite-hybrid-auth-00>. guthrie-noncomposite-hybrid-auth-00>.
[I-D.ietf-lamps-pq-composite-sigs]
Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S.
Fluhrer, "Composite ML-DSA for use in X.509 Public Key
Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-lamps-pq-composite-sigs-06, 18 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-06>.
[KYBERSLASH]
"KyberSlash: Exploiting secret-dependent division timings
in Kyber implementations", 30 June 2024,
<https://eprint.iacr.org/2024/1049>.
[MLDSA] National Institute of Standards and Technology (NIST),
"Module-Lattice-Based Digital Signature Standard", 13
August 2024, <https://doi.org/10.6028/NIST.FIPS.204>.
[NIST_PQC_FAQ] [NIST_PQC_FAQ]
National Institute of Standards and Technology (NIST), NIST, "Post-Quantum Cryptography FAQs", 5 July 2022,
"Post-Quantum Cryptography FAQs", 5 July 2022,
<https://csrc.nist.gov/Projects/post-quantum-cryptography/ <https://csrc.nist.gov/Projects/post-quantum-cryptography/
faqs>. faqs>.
[QRCSP] Bernstein, D., "Quantifying risks in cryptographic [QRCSP] Bernstein, D. J., "Quantifying risks in cryptographic
selection processes", 24 November 2023, selection processes", 24 November 2023,
<https://cr.yp.to/papers/qrcsp-20231124.pdf>. <https://cr.yp.to/papers/qrcsp-20231124.pdf>.
[RAINBOW] "PQC Rainbow", n.d., <https://www.pqcrainbow.org/>. [RAINBOW] "PQC Rainbow", <https://www.pqcrainbow.org/>.
[RSA] Rivest, R. L., Shamir, A., and L. Adleman, "A Method for [RSA] Rivest, R. L., Shamir, A., and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Obtaining Digital Signatures and Public-Key
Cryptosystems", n.d., Cryptosystems",
<https://people.csail.mit.edu/rivest/Rsapaper.pdf>. <https://people.csail.mit.edu/rivest/Rsapaper.pdf>.
Acknowledgements
This document is based on the template of [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
Authors' Addresses Authors' Addresses
Nina Bindel Nina Bindel
SandboxAQ SandboxAQ
Email: nina.bindel@sandboxaq.com Email: nina.bindel@sandboxaq.com
Britta Hale Britta Hale
Naval Postgraduate School Naval Postgraduate School
Email: britta.hale@nps.edu Email: britta.hale@nps.edu
 End of changes. 153 change blocks. 
543 lines changed or deleted 553 lines changed or added

This html diff was produced by rfcdiff 1.48.