rfc9955v1.txt   rfc9955.txt 
Internet Engineering Task Force (IETF) N. Bindel Internet Engineering Task Force (IETF) N. Bindel
Request for Comments: 9955 SandboxAQ Request for Comments: 9955 SandboxAQ
Category: Informational B. Hale Category: Informational B. Hale
ISSN: 2070-1721 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
April 2026 May 2026
Hybrid Signature Spectrums Hybrid Signature Spectrums
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 and forwards compatibility, hybrid hybrid signature, backwards and forwards compatibility, hybrid
generality, and Simultaneous Verification (SV). generality, and Simultaneous Verification (SV).
skipping to change at line 205 skipping to change at line 205
Verify(pk, sig, m) -> b: Verify(pk, sig, m) -> b:
A verification algorithm, which takes as input a public A verification algorithm, which takes as input a public
verifying key pk, a signature sig, and a message m, and outputs verifying key pk, a signature sig, and a message m, and outputs
a bit b indicating accept (b=1) or reject (b=0) of the a bit b indicating accept (b=1) or reject (b=0) of the
signature for the message m. 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 For security purposes, it often makes sense to require that the
the security of the component schemes is based on the hardness of security of the component schemes be based on the hardness of
different cryptographic assumptions, in other cases, hybrid different cryptographic assumptions. However, in some cases,
schemes might be motivated, e.g., by interoperability of variants hybrid schemes might be motivated, e.g., by interoperability of
on the same scheme, and as such, both component schemes are based variants on the same scheme and as such both component schemes
on the same hardness assumption (e.g., both post-quantum would be based on the same hardness assumption (e.g., both post-
assumptions or even both the same concrete assumption, such as quantum assumptions or even both of the same concrete assumption
Ring Learning With Errors (LWE)). We allow this explicitly. In such as Ring Learning With Errors (R-LWE)). We allow this
particular, this means that in contrast to [RFC9794], we will use explicitly. In particular, this means that in contrast to
the more general term 'hybrid signature scheme' instead of [RFC9794], we will use the more general term 'hybrid signature
requiring one post-quantum and one traditional algorithm (i.e., scheme' instead of requiring one post-quantum and one traditional
Post-Quantum Traditional (PQ/T) hybrid signature schemes) to allow algorithm (i.e., Post-Quantum/Traditional (PQ/T) hybrid signature
also the combination of several post-quantum algorithms. The term schemes) to allow also the combination of several post-quantum
'composite scheme' has sometimes been used as a synonym for algorithms. The term 'composite scheme' has sometimes been used
'hybrid scheme'. This is different from [RFC9794] where the term as a synonym for 'hybrid scheme'. This is different from
is used as a specific instantiation of hybrid schemes such that [RFC9794] where the term is used as a specific instantiation of
"where multiple cryptographic algorithms are combined to form a hybrid schemes such that the "scheme is exposed as a singular
single key or signature such that they can be treated as a single interface of the same type as the component algorithms". To avoid
atomic object at the protocol level". To avoid confusion, we will 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 a synonym, we might signature scheme's signature generation. As a synonym, we might
use 'dual signature'. For example, NIST defines a dual signature use 'dual signature'. For example, NIST defines a dual signature
as "two or more signatures on a common message" [NIST_PQC_FAQ]. as "two or more signatures on a common message" [NIST_PQC_FAQ].
For the same reason as above, we will avoid using the term For the same reason as above, we will avoid using the term
'composite signature', although it sometimes appears as a synonym 'composite signature', although it sometimes appears as a synonym
for 'hybrid/dual signature'. for 'hybrid/dual signature'.
Component (signature) scheme: Component signature schemes are the Component (signature) scheme: Component signature schemes are the
skipping to change at line 305 skipping to change at line 304
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
[RFC9954], which summarizes these well. In addition, we explicate [RFC9954], which summarizes these well. In 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 Module-Lattice-Based Digital Signature Algorithm signature scheme Module-Lattice-Based Digital Signature Algorithm
(ML-DSA) [MLDSA] (also known as CRYSTALS-DILITHIUM) follows the well- (ML-DSA) [MLDSA] follows the well-known Fiat-Shamir transform [FS] to
known Fiat-Shamir transform [FS] to construct the signature scheme construct the signature scheme but also relies on rejection sampling
but also relies on rejection sampling that is known to give cache that is known to give cache side channel information (although this
side channel information (although this does not lead to a known does not lead to a known attack). Likewise, the signature scheme
attack). Likewise, the signature scheme FALCON [FALCON] uses complex FALCON [FALCON] uses complex sampling during signature generation.
sampling during signature generation. Furthermore, attacks against Furthermore, attacks against the next-generation multivariate schemes
the next-generation multivariate schemes Rainbow [RAINBOW] and Great Rainbow [RAINBOW] and Great Multivariate Short Signature (GeMSS)
Multivariate Short Signature (GeMSS) [GEMSS] might raise concerns for [GEMSS] might raise concerns for conservative adopters of other
conservative adopters of other algorithms, which could hinder algorithms, which could hinder adoption.
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 algorithm to understand and explain, yet during its existence and
use, 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. Thus, even in a relatively
forgeries). Thus, even in a relatively simple algorithm, subtleties simple algorithm, subtleties and caveats on implementation and use
and caveats on implementation and use can arise over time. Given the can arise over time. Given the complexity of next-generation
complexity of next-generation algorithms, the chance of such algorithms, the chance of such discoveries and caveats needs to be
discoveries and caveats needs to be taken into account. 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 Project [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
skipping to change at line 374 skipping to change at line 372
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 backwards 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 Section 1.3.5). Hybrid authentication is an umbrella
umbrella term that encompasses more specific concepts of hybrid term that encompasses more specific concepts of hybrid signature
signature security, such as 'hybrid unforgeability' described next. 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. For example, the concatenation combiner in
unforgeability'; it is a specific type of hybrid authentication. For [HYBRIDSIG] is 'hybrid unforgeable'. As mentioned above, this might
example, the concatenation combiner in [HYBRIDSIG] is 'hybrid be incompatible with backwards compatibility, where the EUF-CMA
unforgeable'. As mentioned above, this might be incompatible with security of the hybrid signature relies solely on the security of one
backwards compatibility, where the EUF-CMA security of the hybrid of the component schemes instead of relying on both, e.g., the dual
signature relies solely on the security of one of the component message combiner using nesting in [HYBRIDSIG]. For more details,
schemes instead of relying on both, e.g., the dual message combiner refer to Section 1.3.5.
using nesting in [HYBRIDSIG]. For more details, refer to the
discussion below.
Use cases where a hybrid scheme is used with, e.g., EUF-CMA security In some use cases, a hybrid scheme is used with (for example) EUF-CMA
assumed for only one component scheme generally use hybrid techniques security assumed for only one component scheme; these cases generally
for their 'functional transition' pathway support. For example, use hybrid techniques for their 'functional transition' pathway
hybrid signatures may be used as a transition step for gradual post- support. For example, hybrid signatures may be used as a transition
quantum adoption while ensuring interoperability when a system step for gradual post-quantum adoption while ensuring
includes both verifiers that only support traditional signatures and interoperability when a system includes both verifiers that only
verifiers that have been upgraded to support post-quantum signatures. support traditional signatures and 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, in other use cases, a hybrid scheme is used with (for
CMA security assumed for both component schemes without example) EUF-CMA security assumed for both component schemes without
prioritization between them can use hybrid techniques for both prioritization between them; these cases can use hybrid techniques
functional transition and security transition (i.e., a transition to for both functional transition and security transition (i.e., a
ensure security even if it may not be known which algorithm should be transition to ensure security even if it may not be known which
relied upon). algorithm should be 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
building blocks such as hash functions, key derivation functions, building blocks such as hash functions, key derivation functions,
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
skipping to change at line 441 skipping to change at line 438
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 contain attack) but rather implies that such a digital signature will contain
artifacts of the separation. Thus, authentication that is normally artifacts of the separation. Thus, authentication that is normally
assured under correct verification of digital signature(s) is now assured under correct verification of digital signature(s) is now
potentially also reliant on further investigation on the receiver potentially also reliant on further investigation on the receiver
side that may extend well beyond traditional signature verification side that may extend well beyond traditional signature verification
behavior. For instance, this can intuitively be seen in cases of a behavior. For instance, this can intuitively be seen in cases of a
message containing a context note on hybrid authentication that is message containing a context note on hybrid authentication that is
then signed by all component algorithms/the hybrid signature scheme. then signed by all component algorithms as part of the hybrid
If an adversary removes one component signature but not the other, signature scheme. If an adversary removes one component signature
then artifacts in the message itself point to the possible existence but not the other, then artifacts in the message itself point to the
of a hybrid signature such as a label stating "this message must be possible existence of a hybrid signature such as a label stating
hybrid-signed". This might be a countermeasure against stripping "this message must be hybrid-signed". This might be a countermeasure
attacks if the verifier expects a hybrid signature scheme to have against stripping attacks if the verifier expects a hybrid signature
this property. However, it places the responsibility of signature scheme to have this property. However, it places the responsibility
validity not only on the correct format of the message, as in a of signature validity not only on the correct format of the message,
traditional signature security guarantee, but the precise content as in a traditional signature security guarantee, but the precise
thereof. content thereof.
1.3.4. Strong Non-Separability 1.3.4. Strong Non-Separability
Strong Non-Separability (SNS) is a stronger notion of WNS, which is Strong Non-Separability (SNS) is a stronger notion of WNS, which is
introduced in [HYBRIDSIGDESIGN]. SNS guarantees that an adversary introduced in [HYBRIDSIGDESIGN]. SNS guarantees that an adversary
cannot take a hybrid signature (and message) as input and output a cannot take a hybrid signature (and message) as input and output a
valid component signature (and potentially different message) that valid component signature (and potentially different message) that
will verify correctly. In other words, separation of the hybrid will verify correctly. In other words, separation of the hybrid
signature into component signatures implies that the component signature into component signatures implies that the component
signature will fail verification (of the component signature scheme) signature will fail verification (of the component signature scheme)
skipping to change at line 552 skipping to change at line 549
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 signature "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
Similar to performance goals noted for hybridization of other Similar to performance goals noted for hybridization of other
cryptographic components [RFC9954], hybrid signature constructions cryptographic components [RFC9954], hybrid signature constructions
are expected to be as performant as possible. For most hybrid are expected to be as performant as possible. For most hybrid
signatures, this means that the computation time should only signatures, this means that the computation time should only
minimally exceed the sum of the component signature computation time. minimally exceed the sum of the component signature computation time.
It is noted that performance of any variety may come at the cost of It is noted that performance of any variety may 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
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 addition to hybrid certificates (for example, to achieve backwards in addition to hybrid certificates (for example, to achieve backwards
and 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
representing degrees of separability hardness, visualized in spectrum 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* | *Weak Non-Separability*
| |
| Artifacts exist in the message, signature, system, | Artifacts exist in the message, signature, system,
skipping to change at line 629 skipping to change at line 625
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
removed, artifacts of the hybrid will remain (in the message, in the signature is removed, artifacts of the hybridization will remain (in
signature, at the protocol level, etc.). This may enable the the message, in the signature, at the protocol level, etc.). This
verifier to detect if a component signature is stripped away from a may enable the verifier to detect if a component signature is
hybrid signature, but that detectability depends highly on the type stripped away from a hybrid signature, but that detectability depends
of artifact and permissions. For instance, if a message contains a highly on the type of artifact and permissions. For instance, if a
label artifact "This message must be signed with a hybrid signature", message contains a label artifact "This message must be signed with a
then the system must be allowed to analyze the message contents for hybrid signature", then the system must be allowed to analyze the
possible artifacts. Whether a hybrid signature offers (Weak/Strong) message contents for possible artifacts. Whether a hybrid signature
Non-Separability might also depend on the implementation and policy offers (Weak/Strong) Non-Separability might also depend on the
of the protocol or application the hybrid signature is used in on the implementation and policy of the protocol or application the hybrid
verifier side. Such policies may be further ambiguous to the sender, signature is used in on the verifier side. Such policies may be
meaning that the type of authenticity offered to the receiver is further ambiguous to the sender, meaning that the type of
unclear. In another example, under nested signatures, the verifier authenticity offered to the receiver is unclear. In another example,
could be tricked into interpreting a new message as the message/inner under nested signatures, the verifier could be tricked into
signature combination and verify only the outer signature. In this interpreting a new message as the combination of the message and
case, the inner signature is an artifact. inner signature and verify only the outer signature. In this case,
the inner signature is an artifact.
Third on the scale is the Strong Non-Separability notion, in which Third on the spectrum 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 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].
skipping to change at line 706 skipping to change at line 703
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 -- however, artifacts scheme and not directly related to artifacts -- however, artifacts
may be used for detection of separation. 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, resulting in the scheme verifier could indeed ignore the artifact, resulting in the scheme
achieving only weak non-separability and not strong non-separability. achieving only weak non-separability and not strong non-separability.
It is rather that an artifact exists that could be identified if an However, if an investigation occurred, then an artifact could be
investigation occurred, etc. Under weak non-separability, detection identified in the separated signature. Under weak non-separability,
of separation may depend on non-cryptographic configurations or other detection of separation may depend on non-cryptographic
dependencies. Also, strong non-separability and weak non- configurations or other dependencies. Also, strong non-separability
separability are properties of the signature scheme -- artifacts are and weak non-separability are properties of the signature scheme --
not necessarily in the signature and may appear in the signed artifacts are not necessarily in the signature and may appear in the
message, certificate, protocol, or policy (hence them not necessarily signed message, certificate, protocol, or policy (hence them not
being related to the strong non-separability and weak non- necessarily being related to the strong non-separability and weak
separability security notions). Artifacts may still be useful non-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
skipping to change at line 737 skipping to change at line 734
being able to forge the traditional signature, it could remove the being able to forge the traditional signature, it could remove the
label artifact from the message as well. So, for many applications label artifact from the message as well. So, for many applications
and 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 [COMP-MLDSA]. could be in the public key certificates as described in [COMP-MLDSA].
In such a case, the artifacts are still present even if a stripping In such a case, the artifacts are still present even if a stripping
attack occurs. In yet another case, artifacts may be present through attack occurs. In yet another case, artifacts may be present through
the fused hybrid method, thus making them part of the signature at the fused hybrid method, thus making them part of the signature at
the algorithmic level. Note that in this latter case, it is not the algorithmic level. Note that in this latter case, it is not
possible for an adversary to strip one of the component signatures or possible for an adversary to strip one of the component signatures or
use a component of the hybrid to create a forgery for a component use a component of the hybrid signature to create a forgery for a
algorithm. Such signatures provide SNS. Consequently, this also component algorithm. Such signatures provide SNS. Consequently,
implies that the artifacts of hybridization are absolute in that this also implies that the artifacts of hybridization are absolute in
verification failure would occur if an adversary tries to remove that verification failure 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,
skipping to change at line 810 skipping to change at line 807
constructed through the Fiat-Shamir transform, the component constructed through the Fiat-Shamir transform, the component
signatures would include responses r_1 and r_2 and challenges c_1 signatures would include responses r_1 and r_2 and challenges c_1
and c_2, where c_1 and c_2 are hashes computed over the respective and c_2, where c_1 and c_2 are hashes computed over the respective
commitments comm_1 and comm_2 (and the message). A fused hybrid commitments comm_1 and comm_2 (and the message). A fused hybrid
signature could consist of the component responses r_1 and r_2 and signature could consist of the component responses r_1 and r_2 and
a challenge c that is computed as a hash over both commitments, a challenge c that is computed as a hash over both commitments,
i.e., c = Hash((comm_1 || comm_2) || Hash2(message)). As such, c i.e., c = Hash((comm_1 || comm_2) || Hash2(message)). As such, c
does not belong to either of the component signatures but rather does not belong to either of the component signatures 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 |
| | | keys are in separate certs | | | | are in separate certificates |
+----+-----------------------+-----------------------------+ +----+-------------------------+----------------------------------+
| 2 | In message | Label in message, public | | 2 | In message | Label in message, public keys |
| | | keys are in separate certs | | | | are in separate certificates |
+----+-----------------------+-----------------------------+ +----+-------------------------+----------------------------------+
| 3 | In cert | No label in message, public | | 3 | In certificate | No label in message, public keys |
| | | keys are in combined cert | | | | are in combined certificate |
+----+-----------------------+-----------------------------+ +----+-------------------------+----------------------------------+
| 4 | In message and cert | Label in message, public | | 4 | In message and | Label in message, public keys |
| | | keys are in combined cert | | | certificate | are in combined certificate |
+----+-----------------------+=============================+ +----+-------------------------+==================================+
| | | *Nested* | | | | *Nested* |
+----+-----------------------+=============================+ +----+-------------------------+==================================+
| 5 | In message | Label in message, public | | 5 | In message | Label in message, public keys |
| | | keys are in separate certs | | | | are in separate certificates |
+----+-----------------------+-----------------------------+ +----+-------------------------+----------------------------------+
| 6 | In cert | No label in message, public | | 6 | In certificate | No label in message, public keys |
| | | keys are in combined cert | | | | are in combined certificate |
+----+-----------------------+-----------------------------+ +----+-------------------------+----------------------------------+
| 7 | In message and cert | Label in message, public | | 7 | In message and | Label in message, public keys |
| | | keys are in combined cert | | | certificate | are in combined certificate |
+----+-----------------------+=============================+ +----+-------------------------+==================================+
| | | *Fused* | | | | *Fused* |
+----+-----------------------+=============================+ +----+-------------------------+==================================+
| 8 | In signature | Public keys are in separate | | 8 | In signature | Public keys are in separate |
| | | certs | | | | certificates |
+----+-----------------------+-----------------------------+ +----+-------------------------+----------------------------------+
| 9 | In signature and | Label in message, public | | 9 | In signature and | Label in message, public keys |
| | message | keys are in separate certs | | | message | are in separate certificates |
+----+-----------------------+-----------------------------+ +----+-------------------------+----------------------------------+
| 10 | In signature and cert | Public keys are in combined | | 10 | In signature and | Public keys are in combined |
| | | cert | | | certificate | certificate |
+----+-----------------------+-----------------------------+ +----+-------------------------+----------------------------------+
| 11 | In signature and | Label in message, public | | 11 | In signature and | Label in message, public keys |
| | message and cert | keys are in combined cert | | | message and certificate | are in combined certificate |
+----+-----------------------+-----------------------------+ +----+-------------------------+----------------------------------+
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 shown in Table 2, while concatenation may appear to refer to a
type of combiner, there are in fact several possible artifact single 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, this does not imply that every implementation
every implementation using concatenation fails to achieve non- using concatenation fails to achieve non-separability. Thus, it is
separability. Thus, it is advisable for implementers to be advisable for implementers to be transparent about artifact
transparent about artifact locations. 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 approaches, such as cases 3, 4, 6, and 7, solve this circular
dependency 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
skipping to change at line 908 skipping to change at line 904
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-approved software modules is required but applies equally use of FIPS-approved software modules is required but applies equally
to any guidance or policy direction that specifies that at least one to any guidance or policy direction that specifies that at least one
component algorithm of the hybrid has passed some certification type component algorithm of the hybrid scheme has passed some
while not specifying requirements on the other component. NIST certification type while not specifying requirements on the other
provides the following guidance in [NIST_PQC_FAQ] (emphasis added): component. NIST provides the following guidance in [NIST_PQC_FAQ]
(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 | standards in "FIPS mode", as defined in FIPS 140, provided at
| least one of the component methods is a properly implemented, | least one of the component methods is a properly implemented,
| NIST-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. | validity of the hybrid signature.
This document 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 implementers of hybrids may wish to consider when following any that implementers of hybrid signature schemes may wish to consider
guidance documents that specify that 1) the signature scheme for one when following any guidance documents that specify that 1) the
of the component algorithms must be approved and 2) the said signature scheme for one of the component algorithms must be approved
algorithm must be a well-implemented or certified implementation. and 2) the said algorithm must be a well-implemented or certified
This type of need for approval (i.e., a requirement that an implementation. This type of need for approval (i.e., a requirement
implementer is looking to follow regarding approval or certification that an implementer is looking to follow regarding approval or
of the software module implementation of a hybrid or its component certification of the software module implementation of a hybrid or
algorithms) can drive some logistical decisions on what types of its component algorithms) can drive some logistical decisions on what
hybrids an implementer should consider. types of hybrid signature schemes an implementer should consider.
In this respect, there is a scale of approval that developers may In this respect, there is a spectrum 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 spectrum 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 | New signature scheme based on a selection of hardness
| assumptions. | assumptions.
skipping to change at line 984 skipping to change at line 981
| *All Approved Software Modules* | *All Approved Software Modules*
| |
| Hybrid combiner acts as a wrapper, fully independent of | Hybrid combiner acts as a wrapper, fully independent of
| the component signature scheme implementations. | the component signature scheme implementations.
| |
| No new approval needed if at least one component | No new approval needed if at least one component
| implementation is approved. | implementation is approved.
| ---------------------------------------------------------| | ---------------------------------------------------------|
▼ ▼
Figure 2: Generality / Need for Approval Spectrum Figure 2: 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- new, singular algorithm relies on both traditional and next-
generation principles. generation principles.
Next is a combiner that might take inspiration from existing/approved Next is a combiner that might take inspiration from existing/approved
signature schemes such that its security can be reduced to the signature schemes such that its security can be reduced to the
security of the approved algorithms. The combiner may, however, security of the approved algorithms. The combiner may, however,
skipping to change at line 1037 skipping to change at line 1034
security game would be that an adversary requests hybrid signatures security game would be that an adversary requests hybrid signatures
for messages of their choosing and succeeds if they are able to for messages of their choosing and succeeds if they are able to
produce a valid hybrid signature for a message that was not part of produce a valid hybrid signature for a message that was not part of
an earlier request. However, this has several layers of nuance under an earlier request. However, this has several layers of 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 signature scheme, the result would be an
the component signature. This is because as the component signing EUF-CMA forgery for the component signature. This is because as the
algorithm was not previously called for the message, the hybrid component signing algorithm was not previously called for the
signing algorithm was used to generate the signature. This is an message, the hybrid signing algorithm was used to generate the
example of a component algorithm forgery, a.k.a. a case of cross- signature. This is an example of a component algorithm forgery, an
algorithm attack or cross-protocol attack. example of a cross-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 informally defined in the Thus, for a hybrid signature scheme to be EUF-CMA secure, certain
straightforward way as that an adversary requests hybrid signatures requirements must hold. Namely, either component algorithm forgeries
for messages of their choosing and succeeds if they are able to must be out of scope for the use case or the hybrid signature choice
produce a valid hybrid signature for a message that was not part of must be strongly non-separable. Otherwise, component algorithm
an earlier request, implicit requirements must hold in order to avoid forgeries, which can be seen as a type of cross-protocol attack,
real-world implications. Namely, either component algorithm affect the type of EUF-CMA properties offered and are a practical
forgeries, a.k.a. cross-protocol attacks, must be out of scope for consideration that system designers and managers should be aware of
the use case or the hybrid signature choice must be strongly non- when selecting among hybrid approaches for their use case.
separable. Otherwise, component algorithm forgeries, which can be
seen as a type of cross-protocol attack, affect the type of EUF-CMA
properties offered and are a practical consideration that system
designers and managers should be aware of when selecting among hybrid
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
[COMP-MLDSA], prohibiting hybrid algorithm and component algorithm [COMP-MLDSA], prohibiting hybrid algorithm and component algorithm
signers and verifiers from using the same keys can help ensure that a signers and verifiers from using the same keys can help ensure that a
component verifier cannot be tricked into verifying the hybrid component verifier cannot be tricked into verifying the hybrid
signature. This would effectively put component forgeries out of signature. This would effectively put component forgeries out of
scope for a use case. One means for restricting key reuse is through scope for a use case. One means for restricting key reuse is through
allowed key use descriptions in certificates. While prohibiting key allowed key use descriptions in certificates. While prohibiting key
reuse reduces the risk of such component forgeries, and is the reuse reduces the risk of such component forgeries, and is the
skipping to change at line 1121 skipping to change at line 1113
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 in addition
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
skipping to change at line 1170 skipping to change at line 1162
[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/info/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/info/rfc9794>. <https://www.rfc-editor.org/info/rfc9794>.
[RFC9954] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid Key [RFC9954] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid Key
Exchange in TLS 1.3", RFC 9954, DOI 10.17487/RFC9954, Exchange in TLS 1.3", RFC 9954, DOI 10.17487/RFC9954, May
April 2026, <https://www.rfc-editor.org/info/rfc9954>. 2026, <https://www.rfc-editor.org/info/rfc9954>.
9.2. Informative References 9.2. Informative References
[COMP-MLDSA] [COMP-MLDSA]
Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S. Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S.
Fluhrer, "Composite ML-DSA for use in X.509 Public Key Fluhrer, "Composite Module-Lattice-Based Digital Signature
Algorithm (ML-DSA) for use in X.509 Public Key
Infrastructure", Work in Progress, Internet-Draft, draft- Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-lamps-pq-composite-sigs-15, 24 February 2026, ietf-lamps-pq-composite-sigs-19, 21 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-15>. pq-composite-sigs-19>.
[EUFCMA] Green, M., "EUF-CMA and SUF-CMA", [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] Fouque, P., Hoffstein, J., Kirchner, P., Lyubashevsky, V., [FALCON] Fouque, P., Hoffstein, J., Kirchner, P., Lyubashevsky, V.,
Pornin, T., Prest, T., Ricosset, T., Seiler, G., Whyte, Pornin, T., Prest, T., Ricosset, T., Seiler, G., Whyte,
W., and Z. Zhang, "FALCON: Fast-Fourier Lattice-based W., and Z. Zhang, "FALCON: Fast-Fourier Lattice-based
Compact Signatures over NTRU", Specification v1.2, 10 Compact Signatures over NTRU", Specification v1.2, 10
January 2020, <https://falcon-sign.info/falcon.pdf>. January 2020, <https://falcon-sign.info/falcon.pdf>.
skipping to change at line 1242 skipping to change at line 1235
[NC-HYBRID-AUTH] [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>.
[NIST_PQC_FAQ] [NIST_PQC_FAQ]
NIST, "Post-Quantum Cryptography FAQs", 5 July 2022, NIST, "Post-Quantum Cryptography FAQs", 5 July 2022,
<https://csrc.nist.gov/Projects/post-quantum-cryptography/ <https://web.archive.org/web/20220705163944/
https://csrc.nist.gov/Projects/ post-quantum-cryptography/
faqs>. faqs>.
[QRCSP] Bernstein, D. J., "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", <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", Cryptosystems", Communications of the ACM, vol. 21, no. 2,
<https://people.csail.mit.edu/rivest/Rsapaper.pdf>. pp. 120-126, DOI 10.1145/359340.359342,
<https://doi.org/10.1145/359340.359342>.
Acknowledgements Acknowledgements
This document is based on the template of [RFC9954]. This document is based on the template used for [RFC9954].
We would like to acknowledge the following people in alphabetical We would like to acknowledge the following people in alphabetical
order who have contributed to pushing this document forward, offered order who have contributed to pushing this document forward, offered
useful insights and perspectives, and/or stimulated work in the area: useful insights and perspectives, and/or stimulated work in the area:
D.J. Bernstein, Scott Fluhrer, John Gray, Felix Günther, Serge D.J. Bernstein, Scott Fluhrer, John Gray, Felix Günther, Serge
Mister, Mike Ounsworth, Max Pala, Douglas Stebila, Falko Strenzke, Mister, Mike Ounsworth, Max Pala, Douglas Stebila, Falko Strenzke,
and Brendan Zember and Brendan Zember
Authors' Addresses Authors' Addresses
 End of changes. 38 change blocks. 
211 lines changed or deleted 206 lines changed or added

This html diff was produced by rfcdiff 1.48.