Internet Engineering Task Force (IETF) N. Bindel
Request for Comments: 9955 SandboxAQ
Category: Informational B. Hale
ISSN: 2070-1721 Naval Postgraduate School
D. Connolly
SandboxAQ
F. Driscoll
UK National Cyber Security Centre
July 2026
This document describes classification of design goals and security considerations for hybrid digital signature schemes, including proof composability, non-separability of the component signatures given a hybrid signature, backwards and forwards compatibility, hybrid generality, and Simultaneous Verification (SV).
この文書では、ハイブリッドデジタル署名スキームの設計目標の分類とセキュリティ上の考慮事項について説明します。これには、証明の構成可能性、ハイブリッド署名が与えられたコンポーネント署名の非分離性、後方互換性および前方互換性、ハイブリッド汎用性、同時検証 (SV) が含まれます。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the 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 Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。IESG によって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではありません。RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9955.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9955 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Terminology
1.2. Motivation for Use of Hybrid Signature Schemes
1.2.1. Complexity
1.2.2. Time
1.3. Goals
1.3.1. Hybrid Authentication
1.3.2. Proof Composability
1.3.3. Weak Non-Separability
1.3.4. Strong Non-Separability
1.3.5. Backwards and Forwards Compatibility
1.3.6. Simultaneous Verification
1.3.7. Hybrid Generality
1.3.8. High Performance
1.3.9. High Space Efficiency
1.3.10. Minimal Duplicate Information
2. Non-Separability Spectrum
3. Artifacts
3.1. Artifacts vs. Separability
3.2. Artifact Locations
3.3. Artifact Location Comparison Example
4. Need for Approval Spectrum
5. EUF-CMA Challenges
6. Discussion of Advantages and Disadvantages
6.1. Backwards Compatibility vs. SNS
6.2. Backwards Compatibility vs. Hybrid Unforgeability
6.3. Simultaneous Verification vs. Low Need for Approval
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
Plans to transition protocols to post-quantum cryptography sometimes focus on confidentiality, given the potential risk of store and decrypt attacks, where data encrypted today using traditional algorithms could be decrypted in the future by an attacker with a sufficiently powerful quantum computer, also known as a Cryptographically Relevant Quantum Computer (CRQC).
プロトコルをポスト量子暗号に移行する計画では、保存および復号化攻撃の潜在的なリスクを考慮して、機密保持に重点が置かれることがあります。この場合、従来のアルゴリズムを使用して現在暗号化されているデータが、将来、暗号関連量子コンピュータ (CRQC) としても知られる十分に強力な量子コンピュータを備えた攻撃者によって復号化される可能性があります。
It is important to also consider transitions to post-quantum authentication; delaying such transitions creates risks. For example, attackers may be able to carry out quantum attacks against RSA-2048 [RSA] years before the public is aware of these capabilities. Furthermore, there are applications where algorithm turnover is complex or takes a long time. For example, root certificates are often valid for about 20 years or longer. There are also applications where future checks on past authenticity play a role, such as long-lived digital signatures on legal documents.
ポスト量子認証への移行も考慮することが重要です。このような移行を遅らせるとリスクが生じます。たとえば、攻撃者は、RSA-2048 [RSA] に対する量子攻撃を、一般にその機能が知られる数年前に実行できる可能性があります。さらに、アルゴリズムの切り替えが複雑であったり、時間がかかるアプリケーションもあります。たとえば、ルート証明書は多くの場合、約 20 年以上有効です。法的文書の長期有効デジタル署名など、過去の信頼性に対する将来のチェックが役割を果たすアプリケーションもあります。
Still, there have been successful attacks against algorithms using post-quantum cryptography, as well as implementations of such algorithms. Sometimes an attack exploits implementation issues, such as [KYBERSLASH], which exploits timing variations, or [HQC_CVE], which exploits implementation bugs. Sometimes an attack works for all implementations of the specified algorithm. Research indicates that implementation-independent attacks published in 2023 or earlier had broken 48% of the proposals in Round 1 of the NIST Post-Quantum Cryptography Standardization Project, 25% of the proposals not broken by the end of Round 1, and 36% of the proposals selected by NIST for Round 2 [QRCSP].
それでも、ポスト量子暗号を使用したアルゴリズムやその実装に対する攻撃は成功しています。場合によっては、タイミングの変動を悪用する [KYBERSLASH] や実装のバグを悪用する [HQC_CVE] など、実装の問題を悪用する攻撃が行われることがあります。攻撃は、指定されたアルゴリズムのすべての実装に対して機能する場合があります。調査によると、2023 年以前に公開された実装に依存しない攻撃により、NIST ポスト量子暗号標準化プロジェクトのラウンド 1 の提案の 48% が破られ、ラウンド 1 の終了までに破られなかった提案の 25%、およびラウンド 2 [QRCSP] で NIST によって選択された提案の 36% が破られました。
Such cryptanalysis and security concerns are one reason to consider 'hybrid' cryptographic algorithms, which combine both traditional and post-quantum (or more generally a combination of two or more) algorithms. A core objective of hybrid algorithms is to protect against quantum computers while at the same time making clear that the change is not reducing security. A security premise for these algorithms is that if at least one of the two component algorithms of the hybrid scheme holds, the confidentiality or authenticity offered by that scheme is maintained. It should be noted that the word 'hybrid' has many uses, but this document uses 'hybrid' only in this algorithm sense.
このような暗号解析とセキュリティに関する懸念は、従来のアルゴリズムとポスト量子アルゴリズム (より一般的には 2 つ以上の組み合わせ) の両方を組み合わせた「ハイブリッド」暗号アルゴリズムを検討する理由の 1 つです。ハイブリッド アルゴリズムの中核的な目的は、量子コンピューターから保護すると同時に、変更によってセキュリティが低下しないことを明確にすることです。これらのアルゴリズムのセキュリティの前提条件は、ハイブリッド スキームの 2 つのコンポーネント アルゴリズムの少なくとも 1 つが保持される場合、そのスキームによって提供される機密性または信頼性が維持されることです。「ハイブリッド」という言葉には多くの用途がありますが、このドキュメントではこのアルゴリズムの意味でのみ「ハイブリッド」を使用していることに注意してください。
Whether or not hybridization is desired depends on the use case and security threat model. Users may recognize a need to start post-quantum transition, even while issues such as those described above are a concern. For this, hybridization can support transition. It should be noted that hybridization is not necessary for all systems; recommendations on system types or analysis methods for such determination are out of scope of this document. For cases where hybridization is determined to be advantageous, a decision on how to hybridize needs to be made. With many options available, this document is intended to provide context on some of the trade-offs and nuances to consider.
ハイブリッド化が望ましいかどうかは、ユースケースとセキュリティ脅威モデルによって異なります。ユーザーは、上記のような問題が懸念されているにもかかわらず、ポスト量子移行を開始する必要性を認識している可能性があります。このため、ハイブリッド化は移行をサポートできます。ハイブリダイゼーションはすべてのシステムに必要なわけではないことに注意してください。システム タイプやそのような決定のための分析方法に関する推奨事項は、このドキュメントの範囲外です。ハイブリダイゼーションが有利であると判断される場合には、どのようにハイブリダイズするかを決定する必要がある。多くのオプションが利用できるため、このドキュメントは、考慮すべきいくつかのトレードオフとニュアンスについてのコンテキストを提供することを目的としています。
Hybridization of digital signatures, where the hybrid signature may be expected to attest to both standard and post-quantum components, is subtle to design and implement due to the potential separability of the hybrid/dual signatures and the risk of downgrade/stripping attacks. There are also a range of requirements and properties that may be required from hybrid signatures, which will be discussed in this document. Some of these are mutually exclusive, which highlights the importance of considering use-case-specific requirements.
デジタル署名のハイブリッド化は、ハイブリッド署名が標準コンポーネントとポスト量子コンポーネントの両方を証明することが期待される場合がありますが、ハイブリッド/デュアル署名の潜在的な分離可能性とダウングレード/ストリッピング攻撃のリスクにより、設計と実装が困難です。ハイブリッド署名にはさまざまな要件とプロパティが必要になる可能性がありますが、これについてはこのドキュメントで説明します。これらの中には相互に排他的なものもあり、ユースケース固有の要件を考慮することの重要性が強調されています。
This document focuses on explaining a spectrum of different hybrid signature scheme design categories and different security goals for them. It is intended as a resource for designers and implementers of hybrid signature schemes to help them decide what properties they do and do not require from their use case. In scope limitations, it does not attempt to give concrete recommendations for any use case. It also intentionally does not propose concrete hybrid signature combiners or instantiations thereof. As with the data authenticity guarantees provided by any digital signature, the security guarantees discussed in this document are reliant on correct provisioning and management of the keys involved, e.g., entity authentication, key revocation, etc. This document only considers scenarios with a single signer and a single verifier; constructions with multiple signers or verifiers are out of scope.
このドキュメントでは、さまざまなハイブリッド署名スキーム設計カテゴリとそれらのさまざまなセキュリティ目標について説明することに重点を置いています。これは、ハイブリッド署名スキームの設計者と実装者が、ユースケースにどのプロパティを必要とし、どのプロパティを必要としないかを決定するのに役立つリソースとして意図されています。範囲の制限については、いかなるユースケースに対しても具体的な推奨事項を提供するものではありません。また、具体的なハイブリッド署名結合器やそのインスタンス化を意図的に提案していません。デジタル署名によって提供されるデータの信頼性保証と同様、このドキュメントで説明するセキュリティ保証は、エンティティ認証、キー失効など、関連するキーの正しいプロビジョニングと管理に依存します。このドキュメントでは、単一の署名者と単一の検証者によるシナリオのみを考慮します。複数の署名者または検証者がいる構造は範囲外です。
We follow existing documents on hybrid terminology [RFC9794] and hybrid key encapsulation mechanisms (KEMs) [RFC9954] to enable settling on a consistent language. We will make clear when this is not possible. In particular, we follow the definitions of 'post-quantum algorithm', 'traditional algorithm', and 'combiner'. Moreover, we use the definition of 'certificate' to mean 'public-key certificate' as defined in [RFC4949].
私たちは、ハイブリッド用語 [RFC9794] およびハイブリッド キー カプセル化メカニズム (KEM) [RFC9954] に関する既存の文書に従って、一貫した言語の確立を可能にします。これが不可能な場合は明確にさせていただきます。特に、「ポスト量子アルゴリズム」、「従来のアルゴリズム」、「コンバイナー」の定義に従います。さらに、「証明書」の定義は、[RFC4949] で定義されている「公開鍵証明書」を意味するものとして使用します。
Signature scheme:
署名スキーム:
A signature scheme is defined via the following three algorithms:
署名スキームは、次の 3 つのアルゴリズムによって定義されます。
KeyGen() -> (pk, sk):
KeyGen() -> (pk, sk):
A probabilistic key generation algorithm, which generates a public verifying key pk and a secret signing key sk.
確率的鍵生成アルゴリズム。公開検証鍵 pk と秘密署名鍵 sk を生成します。
Sign(sk, m) -> (sig):
符号(sk, m) -> (sig):
A probabilistic signature generation, which takes as input a secret signing key sk and a message m, and outputs a signature sig. In this document, the secret signing key sk is assumed to be implicit for notational simplicity, and the following notation is used: Sign(m) -> (sig). If the message m is comprised of multiple fields, m1, m2, ..., mN, this is notated as Sign(m) = Sign (m1, m2, ... mN) -> (sig).
確率的署名生成。入力として秘密署名鍵 sk とメッセージ m を受け取り、署名 sig を出力します。この文書では、表記を簡単にするために秘密署名鍵 sk は暗黙的であると想定され、Sign(m) -> (sig) という表記が使用されます。メッセージ m が複数のフィールド m1、m2、...、mN で構成されている場合、これは Sign(m) = Sign (m1, m2, ... mN) -> (sig) と表記されます。
Verify(pk, sig, m) -> b:
Verify(pk, sig, m) -> b:
A verification algorithm, which takes as input a public 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 signature for the message m.
公開検証鍵 pk、署名 sig、およびメッセージ m を入力として受け取り、メッセージ m の署名の受け入れ (b=1) または拒否 (b=0) を示すビット b を出力する検証アルゴリズム。
Hybrid signature scheme:
ハイブリッド署名スキーム:
Following [RFC9794], we define a hybrid signature scheme to be "a multi-algorithm digital signature scheme made up of two or more component digital signature algorithms". For security purposes, it often makes sense to require that the security of the component schemes be based on the hardness of different cryptographic assumptions. However, in some cases, hybrid schemes might be motivated, e.g., by interoperability of variants on the same scheme and as such both component schemes would be based on the same hardness assumption (e.g., both post-quantum assumptions or even both the same concrete assumption such as Ring Learning With Errors (R-LWE)). We allow this explicitly. In particular, this means that in contrast to [RFC9794], we will use the more general term 'hybrid signature scheme' instead of requiring one post-quantum and one traditional algorithm (i.e., 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 'hybrid scheme'. This is different from [RFC9794] where the term is used as a specific instantiation of hybrid schemes such that the "scheme is exposed as a singular interface of the same type as the component algorithms". To avoid confusion, we will avoid the term 'composite scheme'.
[RFC9794]に従い、ハイブリッド署名方式を「2つ以上のコンポーネントデジタル署名アルゴリズムで構成されるマルチアルゴリズムデジタル署名方式」と定義します。セキュリティ上の理由から、コンポーネント スキームのセキュリティが、さまざまな暗号化仮定の強度に基づいていることを要求することが合理的であることがよくあります。しかしながら、場合によっては、ハイブリッドスキームは、例えば、同じスキーム上のバリアントの相互運用性によって動機付けられる可能性があり、そのため、両方のコンポーネントスキームは、同じ硬度仮定（例えば、両方のポスト量子仮定、または両方ともエラー付きリング学習（R-LWE）などの同じ具体的な仮定）に基づくことになる。これを明示的に許可します。特に、これは、[RFC9794] とは対照的に、1 つのポスト量子アルゴリズムと 1 つの従来のアルゴリズム (つまり、ポスト量子/従来 (PQ/T) ハイブリッド署名スキーム) を要求する代わりに、より一般的な用語「ハイブリッド署名スキーム」を使用し、複数のポスト量子アルゴリズムの組み合わせも許可することを意味します。「複合スキーム」という用語は、「ハイブリッド スキーム」の同義語として使用されることがあります。これは、この用語が「スキームがコンポーネント アルゴリズムと同じタイプの単一インターフェイスとして公開される」ようなハイブリッド スキームの特定のインスタンス化として使用される [RFC9794] とは異なります。混乱を避けるために、「複合スキーム」という用語は避けます。
Hybrid signature:
ハイブリッド署名:
A hybrid signature is the output of the hybrid signature scheme's signature generation. As a synonym, we might use 'dual signature'. For example, NIST defines a dual signature as "two or more signatures on a common message" [NIST_PQC_FAQ]. For the same reason as above, we will avoid using the term 'composite signature', although it sometimes appears as a synonym for 'hybrid/dual signature'.
ハイブリッド署名は、ハイブリッド署名スキームの署名生成の出力です。同義語として、「二重署名」を使用する場合があります。たとえば、NIST は二重署名を「共通メッセージ上の 2 つ以上の署名」と定義しています [NIST_PQC_FAQ]。上記と同じ理由で、「複合署名」という用語は「ハイブリッド/デュアル署名」の同義語として使用されることもありますが、使用を避けます。
Component (signature) scheme:
コンポーネント (署名) スキーム:
Component signature schemes are the cryptographic algorithms contributing to the hybrid signature scheme. This has a similar purpose as in [RFC9794]. 'Ingredient (signature) scheme' may be used as a synonym.
コンポーネント署名スキームは、ハイブリッド署名スキームに貢献する暗号アルゴリズムです。これは [RFC9794] と同様の目的を持っています。「成分（署名）スキーム」は同義語として使用される場合があります。
Next-generation algorithms:
次世代アルゴリズム:
Following [RFC9954], we define next-generation algorithms to be "algorithms that are not yet widely deployed but may eventually be widely deployed". Hybrid signatures are mostly motivated by preparation for post-quantum transition or use in long-term post-quantum deployment, hence the reference to post-quantum algorithms in this document. However, the majority of the discussion in this document applies equally well to future transitions to other next-generation algorithms.
[RFC9954]に従って、私たちは次世代アルゴリズムを「まだ広く導入されていないが、最終的には広く導入される可能性のあるアルゴリズム」と定義します。ハイブリッド署名は主に、量子後移行の準備、または長期的な量子後展開での使用を目的としているため、このドキュメントでは量子後アルゴリズムについて言及します。ただし、このドキュメントの議論の大部分は、他の次世代アルゴリズムへの将来の移行にも同様に当てはまります。
Policy:
ポリシー：
Throughout this document, we refer to 'policy' in the context of, e.g., a system policy requiring verification of two signatures, an RFC description, guidance documentation, etc. Similar terminology may include 'security configuration settings' or related phrasing. We treat these terms as equivalent for the purposes of this document.
この文書全体を通じて、たとえば 2 つの署名の検証を必要とするシステム ポリシー、RFC の説明、ガイダンス文書などの文脈で「ポリシー」を指します。同様の用語には、「セキュリティ構成設定」または関連する表現が含まれる場合があります。この文書では、これらの用語を同等のものとして扱います。
Artifact:
アーチファクト：
An artifact is evidence of the sender's intent to hybridize a signature that remains even if a component signature is removed. Artifacts can be, e.g., at the algorithmic level (e.g., within the digital signature), at the protocol level (e.g., within the certificate), or on the system policy level (e.g., within the message). Artifacts should be easily identifiable by the receiver in the case of signature stripping.
アーティファクトは、コンポーネント署名が削除された場合でも残る署名をハイブリッド化する送信者の意図の証拠です。アーチファクトは、例えば、アルゴリズムレベル（例えば、デジタル署名内）、プロトコルレベル（例えば、証明書内）、またはシステムポリシーレベル（例えば、メッセージ内）にあり得る。署名除去の場合、受信者はアーティファクトを簡単に識別できる必要があります。
Stripping attack:
ストリッピング攻撃:
A stripping attack refers to a case where an adversary takes a message and hybrid signature pair and attempts to submit (a potential modification of) the pair to a component algorithm verifier, meaning that the security is based only on the remaining component scheme. A common example of a stripping attack includes a message and hybrid signature, comprised of concatenated post-quantum and traditional signatures, where an adversary with a quantum computer simply removes the post-quantum component signature and submits the (potentially changed) message and traditional component signature to a traditional verifier. This could include an authentic traditional certificate authority signature on a certificate that was originally hybrid-signed. An attribute of this is that an honest signer would attest to generating the signature. Stripping attacks should not be confused with component algorithm message forgery attacks.
ストリッピング攻撃とは、攻撃者がメッセージとハイブリッド署名のペアを取得し、そのペア (の潜在的な変更) をコンポーネント アルゴリズム検証者に送信しようとするケースを指します。これは、セキュリティが残りのコンポーネント スキームのみに基づいていることを意味します。ストリッピング攻撃の一般的な例には、連結されたポスト量子署名と従来の署名で構成されるメッセージとハイブリッド署名が含まれます。この場合、量子コンピューターを使用する攻撃者は、単純にポスト量子コンポーネント署名を削除し、(変更された可能性がある) メッセージと従来のコンポーネント署名を従来の検証者に送信します。これには、元々ハイブリッド署名された証明書に、本物の従来の認証局の署名が含まれる可能性があります。この特性の 1 つは、正直な署名者が署名の生成を証明するということです。ストリッピング攻撃をコンポーネント アルゴリズム メッセージ偽造攻撃と混同しないでください。
Component algorithm message forgery attacks:
コンポーネントアルゴリズムのメッセージ偽造攻撃:
A forgery attack refers to a case where an adversary attempts to forge a (non-hybrid) signature on a message using the public key associated with a component algorithm. A common example of such an attack would be a quantum attacker compromising the key associated with a traditional component algorithm and forging a message and signature pair. Message forgery attacks may be formalized with experiments such as the Existential Unforgeability under Chosen Message Attack (EUF-CMA) [EUFCMA], while the difference introduced in component algorithm message forgery attacks is that the key is accepted for both hybrid and single algorithm use. Further discussion of this appears in Section 5.
偽造攻撃とは、攻撃者がコンポーネント アルゴリズムに関連付けられた公開キーを使用してメッセージの (非ハイブリッド) 署名を偽造しようとするケースを指します。このような攻撃の一般的な例は、量子攻撃者が従来のコンポーネント アルゴリズムに関連付けられたキーを侵害し、メッセージと署名のペアを偽造することです。メッセージ偽造攻撃は、Chosen Message Attack (EUF-CMA) [EUFCMA] などの実験によって形式化される場合がありますが、コンポーネント アルゴリズムのメッセージ偽造攻撃に導入される違いは、鍵がハイブリッド アルゴリズムと単一アルゴリズムの両方で使用できることです。これについてはセクション 5 でさらに詳しく説明します。
Before diving into the design goals for hybrid digital signatures, it is worth taking a look at motivations for them. As many of the arguments hold in general for hybrid algorithms, we again refer to [RFC9954], which summarizes these well. In addition, we explicate the motivation for hybrid signatures here.
ハイブリッドデジタル署名の設計目標に入る前に、その動機を検討する価値があります。多くの議論がハイブリッド アルゴリズムに一般的に当てはまるので、これらをよくまとめた [RFC9954] を再度参照します。さらに、ここではハイブリッド署名の動機について説明します。
Next-generation algorithms and their underlying hardness assumptions are often more complex than traditional algorithms. For example, the signature scheme Module-Lattice-Based Digital Signature Algorithm (ML-DSA) [MLDSA] follows the well-known Fiat-Shamir transform [FS] to construct the signature scheme but also relies on rejection sampling that is known to give cache side channel information (although this does not lead to a known attack). Likewise, the signature scheme FALCON [FALCON] uses complex sampling during signature generation. Furthermore, attacks against the next-generation multivariate schemes Rainbow [RAINBOW] and Great Multivariate Short Signature (GeMSS) [GEMSS] might raise concerns for conservative adopters of other algorithms, which could hinder adoption.
次世代アルゴリズムとその基礎となる硬度の仮定は、多くの場合、従来のアルゴリズムよりも複雑です。たとえば、署名スキーム モジュール格子ベースのデジタル署名アルゴリズム (ML-DSA) [MLDSA] は、よく知られている Fiat-Shamir 変換 [FS] に従って署名スキームを構築しますが、キャッシュ サイド チャネル情報を与えることが知られている拒否サンプリングにも依存します (ただし、これは既知の攻撃にはつながりません)。同様に、署名スキーム FALCON [FALCON] は、署名生成中に複雑なサンプリングを使用します。さらに、次世代の多変量スキームである Rainbow [RAINBOW] および Great Multivariate Short Signature (GeMSS) [GEMSS] に対する攻撃は、他のアルゴリズムの保守的な採用者に懸念を引き起こし、採用を妨げる可能性があります。
As such, some next-generation algorithms carry a higher risk of implementation mistakes and revision of parameters compared to traditional algorithms, such as RSA. RSA is a relatively simple algorithm to understand and explain, yet during its existence and use, there have been multiple attacks and refinements, such as adding requirements to how padding and keys are chosen, and implementation issues, such as cross-protocol attacks (as may be caused by component algorithm forgeries). Thus, even in a relatively simple algorithm, subtleties and caveats on implementation and use can arise over time. Given the complexity of next-generation algorithms, the chance of such discoveries and caveats needs to be taken into account.
そのため、一部の次世代アルゴリズムは、RSA などの従来のアルゴリズムと比較して、実装ミスやパラメーターの改訂のリスクが高くなります。RSA は理解して説明するのが比較的簡単なアルゴリズムですが、その存在と使用の間に、パディングとキーの選択方法への要件の追加や、クロスプロトコル攻撃 (コンポーネント アルゴリズムの偽造によって引き起こされる可能性がある) などの実装の問題など、複数の攻撃と改良が行われてきました。したがって、比較的単純なアルゴリズムであっても、時間の経過とともに、実装および使用に関する微妙な点や注意事項が生じる可能性があります。次世代アルゴリズムの複雑さを考慮すると、そのような発見や警告が発生する可能性を考慮する必要があります。
Of note, some next-generation algorithms have received considerable analysis, for example, following attention gathered during the NIST Post-Quantum Cryptography Standardization Project [NIST_PQC_FAQ]. However, if and when further information on caveats and implementation issues come to light, it is quite possible that vulnerabilities will represent a weakening of security rather than a full "break". Such weakening may also be offset if a hybrid approach has been used.
注目すべきことに、一部の次世代アルゴリズムは、たとえば、NIST ポスト量子暗号標準化プロジェクト [NIST_PQC_FAQ] 中に集められた注目を受けて、かなりの分析を受けています。ただし、注意事項や実装上の問題に関するさらなる情報が明らかになった場合、脆弱性は完全な「破壊」ではなく、セキュリティの弱体化を意味する可能性が十分にあります。ハイブリッドアプローチが使用されている場合、このような弱体化も相殺される可能性があります。
In large systems, including national systems, space systems, large healthcare support systems, and critical infrastructure, acquisition and procurement time can be measured in years, and algorithm replacement may be difficult or even practically impossible. Long-term commitment creates further urgency for immediate post-quantum algorithm selection, for example, when generating root certificates with their long validity windows. Additionally, for some sectors, future checks on past authenticity plays a role (e.g., many legal, financial, auditing, and governmental systems). This means there is a need to transition some systems to post-quantum signature algorithms imminently. However, as described above, there is a need to remain aware of potential, hidden subtleties in next-generation algorithms' resistance to standard attacks, particularly in cases where it is difficult to replace algorithms. This combination of time pressure and complexity drives some transition designs towards hybridization.
国家システム、宇宙システム、大規模な医療支援システム、重要なインフラストラクチャなどの大規模システムでは、取得と調達に数年かかる場合があり、アルゴリズムの置き換えが困難であるか、事実上不可能になる場合があります。長期的なコミットメントにより、たとえば有効期間が長いルート証明書を生成する場合など、即時ポスト量子アルゴリズムの選択がさらに緊急になります。さらに、一部のセクターでは、過去の信頼性に対する将来のチェックが重要な役割を果たします (例: 多くの法律、財務、監査、および政府のシステム)。これは、一部のシステムをポスト量子署名アルゴリズムに早急に移行する必要があることを意味します。ただし、上で説明したように、特にアルゴリズムの置き換えが難しい場合には、標準的な攻撃に対する次世代アルゴリズムの耐性における潜在的な隠れた微妙な点に常に注意を払う必要があります。この時間的プレッシャーと複雑さの組み合わせにより、一部の移行設計はハイブリッド化に向けて推進されます。
There are various security and usability goals that can be achieved through hybridization. The following provides a summary of these goals while also noting where goals are in conflict, i.e., that achievement of one goal precludes another, such as backwards compatibility.
ハイブリッド化によって達成できるセキュリティと使いやすさのさまざまな目標があります。以下に、これらの目標の概要を示します。また、目標が矛盾する場所、つまり、下位互換性など、1 つの目標を達成すると別の目標が妨げられることにも注意します。
One goal of hybrid signature schemes is security. As defined in [RFC9794], ideally a hybrid signature scheme can achieve 'hybrid authentication', which is the property that (cryptographic) authentication is achieved by the hybrid signature scheme, provided that a least one component signature algorithm remains 'secure'. There might be, however, other goals in competition with this one, such as backwards compatibility -- referring to the property where a hybrid signature may be verified by only verifying one component signature (see Section 1.3.5). Hybrid authentication is an umbrella term that encompasses more specific concepts of hybrid signature security, such as 'hybrid unforgeability' described next.
ハイブリッド署名方式の目標の 1 つはセキュリティです。[RFC9794] で定義されているように、理想的には、ハイブリッド署名スキームは「ハイブリッド認証」を達成できます。これは、少なくとも 1 つのコンポーネント署名アルゴリズムが「安全」なままであれば、(暗号) 認証がハイブリッド署名スキームによって達成されるという特性です。ただし、下位互換性など、この目標と競合する他の目標が存在する可能性があります。これは、1 つのコンポーネント署名を検証するだけでハイブリッド署名を検証できる特性を指します (セクション 1.3.5 を参照)。ハイブリッド認証は、次に説明する「ハイブリッド偽造防止機能」など、ハイブリッド署名セキュリティのより具体的な概念を含む包括的な用語です。
Hybrid unforgeability is a specific type of hybrid authentication, where the security assumption for the scheme (e.g., EUF-CMA) is maintained as long as at least one of the component schemes maintains that security assumption. For example, the concatenation combiner in [HYBRIDSIG] is 'hybrid unforgeable'. As mentioned above, this might be incompatible with backwards compatibility, where the EUF-CMA security of the hybrid signature relies solely on the security of one of the component schemes instead of relying on both, e.g., the dual message combiner using nesting in [HYBRIDSIG]. For more details, refer to Section 1.3.5.
ハイブリッド偽造防止機能は、ハイブリッド認証の特定のタイプであり、コンポーネント スキームの少なくとも 1 つがセキュリティの前提を維持する限り、スキーム (EUF-CMA など) のセキュリティの前提が維持されます。たとえば、[HYBRIDSIG] の連結結合器は「ハイブリッド不可能」です。上で述べたように、これは下位互換性と互換性がない可能性があります。つまり、ハイブリッド署名の EUF-CMA セキュリティは、コンポーネント スキームの両方に依存するのではなく、コンポーネント スキームの 1 つのセキュリティのみに依存します (たとえば、[HYBRIDSIG] のネストを使用するデュアル メッセージ コンバイナなど)。詳細については、セクション 1.3.5 を参照してください。
In some use cases, a hybrid scheme is used with, e.g., EUF-CMA security assumed for only one component scheme. Such cases generally use hybrid techniques for their 'functional transition' pathway support. For example, hybrid signatures may be used as a transition step for gradual post-quantum adoption while ensuring interoperability when a system includes both verifiers that only support traditional signatures and verifiers that have been upgraded to support post-quantum signatures.
いくつかの使用例では、ハイブリッド方式が使用され、たとえば、1 つのコンポーネント方式のみを想定した EUF-CMA セキュリティが使用されます。このようなケースでは通常、「機能移行」経路のサポートにハイブリッド技術が使用されます。たとえば、ハイブリッド署名は、従来の署名のみをサポートする検証器と、量子後署名をサポートするようにアップグレードされた検証器の両方がシステムに含まれている場合、相互運用性を確保しながら、段階的な量子後導入への移行ステップとして使用できます。
In contrast, for use cases where a hybrid scheme with, e.g., EUF-CMA security assumed for both component schemes without prioritization between them, hybrid techniques can be used for both functional transition and security transition (i.e., a transition to ensure security even if it may not be known which algorithm should be relied upon).
対照的に、例えば EUF-CMA セキュリティを備えたハイブリッド方式が、それらの間で優先順位付けを行わずに両方のコンポーネント方式に対して想定されるユースケースでは、機能移行とセキュリティ移行 (つまり、どのアルゴリズムに依存する必要があるかが不明な場合でもセキュリティを確保するための移行) の両方にハイブリッド技術を使用できます。
Under proof composability, the component algorithms are combined in 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 the respective component signature schemes and, potentially, other building blocks such as hash functions, key derivation functions, etc. Otherwise, an entirely new proof of security is required, and there is a lack of assurance that the combination builds on the standardization processes and analysis performed to date on component algorithms. The resulting hybrid signature would be, in effect, an entirely new algorithm of its own. The more the component signature schemes are entangled, the more likely it is that an entirely new proof is required, thus not meeting proof composability.
証明構成可能性の下では、コンポーネント アルゴリズムは、ハイブリッド署名スキームのセキュリティ特性から、それぞれのコンポーネント署名スキームのプロパティ、および場合によってはハッシュ関数や鍵導出関数などの他の構成要素へのセキュリティの低減を証明できる方法で結合されます。そうでない場合は、まったく新しいセキュリティ証明が必要となり、その組み合わせがコンポーネント アルゴリズムに関してこれまでに実行された標準化プロセスと分析に基づいて構築されているという保証が不足します。結果として得られるハイブリッド署名は、事実上、独自のまったく新しいアルゴリズムになります。コンポーネントの署名スキームが複雑になるほど、まったく新しい証明が必要となり、証明の構成可能性を満たせなくなる可能性が高くなります。
Non-separability was one of the earliest properties of hybrid digital signatures to be discussed [HYBRIDSIG]. It was defined as the guarantee that an adversary cannot simply "remove" one of the component signatures without evidence left behind. For example, there are artifacts that a carefully designed verifier may be able to identify or that are identifiable in later audits. This was later termed Weak Non-Separability (WNS) [HYBRIDSIGDESIGN]. Note that WNS does not restrict an adversary from potentially creating a valid component digital signature from a hybrid one (a signature stripping attack) but rather implies that such a digital signature will contain artifacts of the separation. Thus, authentication that is normally assured under correct verification of digital signature(s) is now potentially also reliant on further investigation on the receiver side that may extend well beyond traditional signature verification behavior. For instance, this can intuitively be seen in cases of a message containing a context note on hybrid authentication that is then signed by all component algorithms as part of the hybrid signature scheme. If an adversary removes one component signature but not the other, then artifacts in the message itself point to the possible existence of a hybrid signature such as a label stating "this message must be hybrid-signed". This might be a countermeasure against stripping attacks if the verifier expects a hybrid signature scheme to have this property. However, it places the responsibility of signature validity not only on the correct format of the message, as in a traditional signature security guarantee, but the precise content thereof.
非分離性は、議論されるようになったハイブリッドデジタル署名の最も初期の特性の 1 つでした [HYBRIDSIG]。これは、攻撃者が証拠を残さずにコンポーネントの署名の 1 つを単純に「削除」できないことを保証するものとして定義されました。たとえば、慎重に設計された検証者が識別できる可能性のある成果物や、後の監査で識別できる成果物があります。これは後に弱い非分離性 (WNS) [HYBRIDSIGDESIGN] と呼ばれるようになりました。WNS は、攻撃者がハイブリッド署名から有効なコンポーネントのデジタル署名を作成する可能性 (署名ストリッピング攻撃) を制限するものではなく、そのようなデジタル署名には分離のアーティファクトが含まれることを暗示していることに注意してください。したがって、通常はデジタル署名の正しい検証の下で保証される認証は、現在では受信側でのさらなる調査に依存する可能性があり、これは従来の署名検証動作をはるかに超えている可能性があります。たとえば、これは、ハイブリッド署名スキームの一部としてすべてのコンポーネント アルゴリズムによって署名される、ハイブリッド認証に関するコンテキスト ノートを含むメッセージの場合に直感的にわかります。攻撃者が一方のコンポーネント署名を削除し、もう一方のコンポーネント署名を削除しなかった場合、メッセージ自体内のアーティファクトは、「このメッセージはハイブリッド署名されている必要がある」というラベルなどのハイブリッド署名が存在する可能性を示します。これは、検証者がハイブリッド署名スキームにこの特性があることを期待している場合、ストリッピング攻撃に対する対抗策となる可能性があります。ただし、従来の署名のセキュリティ保証のように、署名の有効性はメッセージの正しい形式だけでなく、その正確な内容にも責任が課されます。
Strong Non-Separability (SNS) is a stronger notion of WNS, which is introduced in [HYBRIDSIGDESIGN]. SNS guarantees that an adversary cannot take a hybrid signature (and message) as input and output a valid component signature (and potentially different message) that will verify correctly. In other words, separation of the hybrid signature into component signatures implies that the component signature will fail verification (of the component signature scheme) entirely. Therefore, authentication is provided by the sender to the receiver through correct verification of the digital signature(s), as in traditional signature security experiments. It is not dependent on other components, such as message content checking, or protocol-level aspects, such as public key provenance. As an illustrative example distinguishing WNS from SNS, consider the case of component algorithms Sigma_1.Sign and Sigma_2.Sign where the hybrid signature is computed as a concatenation (sig_1, sig_2), where sig_1 = Sigma_1.Sign(hybridAlgID, m) and sig_2 = Sigma_2.Sign(hybridAlgID, m). In this case, a new message m' = (hybridAlgID, m) along with signature sig_1 and Sigma_1.pk, with the hybrid artifact embedded in the message instead of the signature, could be correctly verified. The separation would be identifiable through further investigation, but the signature verification itself would not fail. Thus, this case shows WNS (assuming the verification algorithm is defined accordingly) but not SNS.
強力な非分離性 (SNS) は、[HYBRIDSIGDESIGN] で導入された WNS のより強力な概念です。SNS は、攻撃者がハイブリッド署名 (およびメッセージ) を入力として受け取り、正しく検証される有効なコンポーネント署名 (および場合によっては異なるメッセージ) を出力できないことを保証します。言い換えれば、ハイブリッド署名をコンポーネント署名に分離することは、コンポーネント署名が (コンポーネント署名スキームの) 検証に完全に失敗することを意味します。したがって、従来の署名セキュリティ実験と同様に、デジタル署名の正しい検証を通じて、送信者から受信者に認証が提供されます。これは、メッセージ内容のチェックなどの他のコンポーネントや、公開キーの出所などのプロトコル レベルの側面には依存しません。WNS と SNS を区別する例として、ハイブリッド署名が連結 (sig_1, sig_2) として計算されるコンポーネント アルゴリズム Sigma_1.Sign および Sigma_2.Sign のケースを考えます。ここで、sig_1 = Sigma_1.Sign(hybridAlgID, m) および sig_2 = Sigma_2.Sign(hybridAlgID, m) です。この場合、署名の代わりにハイブリッド アーティファクトがメッセージに埋め込まれた、新しいメッセージ m' = (hybridAlgID, m) と署名 sig_1 および Sigma_1.pk は正しく検証できます。さらなる調査によって分離は特定可能になりますが、署名の検証自体は失敗しません。したがって、このケースでは WNS (検証アルゴリズムがそれに応じて定義されていると仮定) が示されていますが、SNS は示されていません。
Some work [COMP-MLDSA] has looked at reliance on the public key certificate chains to explicitly define hybrid use of the public key, namely that Sigma_1.pk cannot be used without Sigma_2.pk. This implies pushing the hybrid artifacts into the protocol and system level and a dependency on the security of other verification algorithms (namely those in the certificate chain). This further requires that security analysis of a hybrid digital signature requires analysis of the key provenance, i.e., not simply that a valid public key is used but how its hybridization and hybrid artifacts have been managed throughout the entire chain. External dependencies such as this may imply hybrid artifacts lie outside the scope of the signature algorithm itself. SNS may potentially be achievable based on dependencies at the system level.
いくつかの研究 [COMP-MLDSA] は、公開鍵のハイブリッド使用を明示的に定義するために、公開鍵証明書チェーンへの依存を検討しています。つまり、Sigma_1.pk は Sigma_2.pk なしでは使用できないということです。これは、ハイブリッド アーティファクトをプロトコルおよびシステム レベルにプッシュし、他の検証アルゴリズム (つまり、証明書チェーン内のアルゴリズム) のセキュリティに依存することを意味します。これにはさらに、ハイブリッドデジタル署名のセキュリティ分析には鍵の来歴、つまり、単に有効な公開鍵が使用されているかどうかだけでなく、そのハイブリッド化とハイブリッド成果物がチェーン全体でどのように管理されているかの分析が必要であることが求められます。このような外部依存関係は、ハイブリッド アーティファクトが署名アルゴリズム自体の範囲外にあることを意味する可能性があります。SNS は、システム レベルでの依存関係に基づいて実現できる可能性があります。
Backwards compatibility refers to the property where a hybrid signature may be verified by only verifying one component signature, allowing the scheme to be used by legacy receivers. In general, this means verifying the traditional component signature scheme, potentially ignoring the post-quantum signature entirely. This provides an option to transition sender systems to post-quantum algorithms while still supporting select legacy receivers. Notably, this is a verification property; the sender has provided a hybrid digital signature, but the verifier is allowed, due to internal policy and/or implementation, to only verify one component signature.
下位互換性とは、ハイブリッド署名が 1 つのコンポーネント署名のみを検証することによって検証され、レガシー受信機によるスキームの使用を可能にする特性を指します。一般に、これは従来のコンポーネント署名スキームを検証することを意味し、ポスト量子署名を完全に無視する可能性があります。これにより、選択されたレガシー受信機をサポートしながら、送信側システムをポスト量子アルゴリズムに移行するオプションが提供されます。特に、これは検証プロパティです。送信者はハイブリッドデジタル署名を提供しましたが、内部ポリシーおよび/または実装により、検証者は 1 つのコンポーネント署名のみを検証することが許可されています。
Forwards compatibility has also been a consideration in hybrid proposals [NC-HYBRID-AUTH]. Forwards compatibility assumes that hybrid signature schemes will be used for some time but that eventually all systems will transition to use only one (particularly, only one post-quantum) algorithm. As this is very similar to backwards compatibility, it also may imply separability of a hybrid algorithm; however, it could also simply imply capability to support separate component signatures. Thus, the key distinction between backwards and forwards compatibility is that backwards compatibility may be needed for legacy systems that cannot use and/or process hybrid or post-quantum signatures, whereas in forwards compatibility, the system has those capabilities and can choose what to support (e.g., for efficiency reasons).
ハイブリッド提案 [NC-HYBRID-AUTH] では、前方互換性も考慮されています。上位互換性は、ハイブリッド署名方式がしばらく使用されることを前提としていますが、最終的にはすべてのシステムが 1 つのアルゴリズムのみ (特に、ポスト量子アルゴリズムを 1 つだけ使用する) に移行することを前提としています。これは下位互換性と非常に似ているため、ハイブリッド アルゴリズムの分離可能性を意味する場合もあります。ただし、単に個別のコンポーネント署名をサポートする機能を意味することもあります。したがって、後方互換性と後方互換性の重要な違いは、後方互換性は、ハイブリッド署名やポスト量子署名を使用および/または処理できないレガシー システムに必要な場合があるのに対し、前方互換性では、システムがそれらの機能を備えており、何をサポートするかを選択できることです (効率上の理由など)。
Ideally, backwards and forwards compatibility is achieved using redundant information as little as possible, as noted in [RFC9954].
[RFC9954] に記載されているように、後方互換性と前方互換性は、冗長な情報を最小限に抑えて達成されるのが理想的です。
Simultaneous Verification (SV) builds on SNS and was first introduced in [HYBRIDSIGDESIGN]. SV requires that not only is the entire hybrid signature (e.g., all component signature elements) needed to achieve a successful verification present in the signature presented for verification but also that verification of both component algorithms occurs roughly simultaneously. Namely, "missing" information needs to be computed by the verifier so that a normally functioning verification algorithm cannot "quit" the verification process before the hybrid signature elements attesting for both component algorithms are verified. This may additionally cover some error-injection and similar attacks, where an adversary attempts to make an otherwise honest verifier skip component algorithm verification. SV mimics traditional digital signatures guarantees, essentially ensuring that the hybrid digital signature behaves as a single algorithm vs. two separate component stages. Alternatively phrased, under an SV guarantee, it is not possible for an otherwise honest verifier to initiate termination of the hybrid verification upon successful verification of one component algorithm without also knowing if the other component succeeded. Note that SV does not prevent dishonest verification, such as if a verifier maliciously implements a customized verification algorithm that is designed with intention to subvert the hybrid verification process or skips signature verification altogether.
同時検証 (SV) は SNS 上に構築され、[HYBRIDSIGDESIGN] で初めて導入されました。SV では、検証を成功させるために必要なハイブリッド署名全体 (すべてのコンポーネントの署名要素など) が検証のために提示された署名に存在するだけでなく、両方のコンポーネントのアルゴリズムの検証がほぼ同時に行われることも必要とします。つまり、両方のコンポーネントアルゴリズムを証明するハイブリッド署名要素が検証される前に、正常に機能する検証アルゴリズムが検証プロセスを「終了」できないように、「欠落」情報を検証者が計算する必要があります。これは、敵対者が他の正当な検証者にコンポーネント アルゴリズムの検証をスキップさせようとする、一部のエラー挿入や同様の攻撃もカバーする可能性があります。SV は従来のデジタル署名保証を模倣し、基本的にハイブリッド デジタル署名が 2 つの個別のコンポーネント ステージに対して単一のアルゴリズムとして動作することを保証します。別の言い方をすれば、SV 保証の下では、他のコンポーネントが成功したかどうかも知らずに、一方のコンポーネントのアルゴリズムの検証が成功した場合に、そうでなければ誠実な検証者がハイブリッド検証の終了を開始することは不可能です。SV は、ハイブリッド検証プロセスを破壊することを意図して設計されたカスタマイズされた検証アルゴリズムを検証者が悪意を持って実装したり、署名検証を完全にスキップしたりする場合など、不正な検証を防ぐことはできないことに注意してください。
Hybrid generality means that a general signature combiner is defined based on inherent and common structures of component digital signature "categories". For instance, since multiple signature schemes use a Fiat-Shamir transform, a hybrid scheme based on the transform can be made that is generalizable to all such signatures. Such generality can also result in simplified constructions, whereas more tailored hybrid variants might be more efficient in terms of sizes and performance.
ハイブリッド汎用性とは、コンポーネントデジタル署名「カテゴリ」の固有の共通構造に基づいて一般署名結合器が定義されることを意味します。たとえば、複数の署名スキームはフィアット シャミア変換を使用するため、そのようなすべての署名に一般化できる、変換に基づくハイブリッド スキームを作成できます。このような汎用性により、構造が簡素化される可能性もありますが、よりカスタマイズされたハイブリッドのバリアントは、サイズとパフォーマンスの点でより効率的になる可能性があります。
Similar to performance goals noted for hybridization of other cryptographic components [RFC9954], hybrid signature constructions are expected to be as performant as possible. For most hybrid signatures, this means that the computation time should only minimally exceed the sum of the component signature computation time. It is noted that performance of any variety may come at the cost of other properties, such as hybrid generality.
他の暗号化コンポーネント [RFC9954] のハイブリッド化に関して示されたパフォーマンス目標と同様に、ハイブリッド署名構築には可能な限りのパフォーマンスが期待されます。ほとんどのハイブリッド署名の場合、これは、計算時間がコンポーネント署名の計算時間の合計を最小限に超える必要があることを意味します。あらゆる種類のパフォーマンスは、ハイブリッド汎用性などの他の特性を犠牲にして得られる可能性があることに注意してください。
Hybrid signature constructions are expected to be as space performant as possible. This includes messages (as they might increase if artifacts are used), public keys, and the hybrid signature. For the hybrid signature, size should no more than minimally exceed the signature size of the two component signatures. In some cases, it may be possible for a hybrid signature to be smaller than the concatenation of the two component signatures.
ハイブリッド署名構造は、可能な限りスペース性能が高いことが期待されます。これには、メッセージ (アーティファクトが使用されると増加する可能性があるため)、公開鍵、およびハイブリッド署名が含まれます。ハイブリッド署名の場合、サイズは 2 つのコンポーネント署名の署名サイズを最小限超えてはなりません。場合によっては、ハイブリッド署名が 2 つのコンポーネント署名を連結したものよりも小さくなる可能性があります。
Duplicated information should be avoided when possible, as a general point of efficiency. This might include repeated information in hybrid certificates or in the communication of component certificates in addition to hybrid certificates (for example, to achieve backwards and forwards compatibility) or sending multiple public keys or signatures of the same component algorithm.
一般的な効率性の観点から、情報の重複は可能な限り避けるべきです。これには、ハイブリッド証明書内の繰り返し情報や、ハイブリッド証明書に加えてコンポーネント証明書の通信 (たとえば、下位互換性と上位互換性を実現するため)、または同じコンポーネント アルゴリズムの複数の公開キーや署名の送信に情報が繰り返されることが含まれる場合があります。
Non-separability is not a singular definition but rather is a spectrum representing degrees of separability hardness, visualized in Figure 1.
非分離性は単一の定義ではなく、分離性の硬さの度合いを表すスペクトルであり、図 1 に視覚化されています。
| ----------------------------------------------------------|
| *No Non-Separability*
|
| No artifacts exist.
| ----------------------------------------------------------|
| *Weak Non-Separability*
|
| Artifacts exist in the message, signature, system,
| application, or protocol.
| ----------------------------------------------------------|
| *Strong Non-Separability*
|
| Artifacts exist in the hybrid signature.
| ----------------------------------------------------------|
| *Strong Non-Separability with Simultaneous Verification*
|
| Artifacts exist in the hybrid signature, and verification
| or failure of both components occurs simultaneously.
| ----------------------------------------------------------|
V
Figure 1: Spectrum of Non-Separability from Weakest to Strongest
図 1: 最も弱いものから最も強いものまでの非分離性のスペクトル
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 detect the change during verification. An example of this includes simple concatenation of signatures without any artifacts used. Nested signatures (where a message is signed by one component algorithm and then the message-signature combination is signed by the second component algorithm) may also fall into this category, dependent on whether the inner or outer signature is stripped off without any artifacts remaining.
スペクトルの一端には、検証者が検証中に変更を検出できない状態で、コンポーネントの署名の 1 つが削除される可能性があるスキームがあります。この例には、アーティファクトを使用しない署名の単純な連結が含まれます。ネストされた署名 (メッセージが 1 つのコンポーネント アルゴリズムによって署名され、その後、メッセージと署名の組み合わせが 2 番目のコンポーネント アルゴリズムによって署名される) も、アーティファクトを残さずに内側または外側の署名が剥ぎ取られるかどうかに応じて、このカテゴリに分類される場合があります。
Next on the spectrum are weakly non-separable signatures. Under Weak Non-Separability, if one of the component signatures of a hybrid signature is removed, artifacts of the hybridization will remain (in the message, in the signature, at the protocol level, etc.). This may enable the verifier to detect if a component signature is stripped away from a hybrid signature, but that detectability depends highly on the type of artifact and permissions. For instance, if a message contains a label artifact "This message must be signed with a hybrid signature", then the system must be allowed to analyze the message contents for possible artifacts. Whether a hybrid signature offers (Weak/Strong) Non-Separability might also depend on the implementation and policy of the protocol or application the hybrid signature is used in on the verifier side. Such policies may be further ambiguous to the sender, meaning that the type of authenticity offered to the receiver is unclear. In another example, under nested signatures, the verifier could be tricked into interpreting a new message as the combination of the message and inner signature and verify only the outer signature. In this case, the inner signature is an artifact.
次に、弱く分離不可能な署名です。弱い非分離性では、ハイブリッド署名のコンポーネント署名の 1 つが削除された場合、ハイブリッド化のアーティファクトが (メッセージ内、署名内、プロトコル レベルなどで) 残ります。これにより、検証者はコンポーネント署名がハイブリッド署名から剥がされているかどうかを検出できるようになりますが、その検出可能性はアーティファクトのタイプと権限に大きく依存します。たとえば、メッセージに「このメッセージはハイブリッド署名で署名する必要があります」というラベル アーティファクトが含まれている場合、システムはメッセージの内容を分析してアーティファクトの可能性を確認できる必要があります。ハイブリッド署名が (弱い/強い) 非分離性を提供するかどうかは、検証者側でハイブリッド署名が使用されるプロトコルまたはアプリケーションの実装とポリシーにも依存する可能性があります。このようなポリシーは送信者にとってさらに曖昧になる可能性があり、受信者に提供される真正性の種類が不明確になる可能性があります。別の例では、ネストされた署名の下では、検証者がだまされて新しいメッセージをメッセージと内部署名の組み合わせとして解釈させ、外部署名のみを検証する可能性があります。この場合、内部署名はアーティファクトです。
Third on the spectrum is the Strong Non-Separability notion, in which separability detection is dependent on artifacts in the signature itself. Unlike in Weak Non-Separability, where artifacts may be in the actual message, the certificate, or other non-signature components, this notion more closely ties to traditional algorithm security notions (such as EUF-CMA) where security is dependent on the internal construct of the signature algorithm and its verification. In this type, the verifier can detect artifacts on an algorithmic level during verification. For example, the signature itself may encode the information that a hybrid signature scheme is used. Examples of this type may be found in [HYBRIDSIGDESIGN].
スペクトルの 3 番目は、強力な非分離性の概念です。この概念では、分離性の検出は署名自体のアーティファクトに依存します。アーティファクトが実際のメッセージ、証明書、またはその他の非署名コンポーネントに存在する可能性がある弱い非分離性とは異なり、この概念は、セキュリティが署名アルゴリズムの内部構造とその検証に依存する従来のアルゴリズム セキュリティ概念 (EUF-CMA など) により密接に関係しています。このタイプでは、検証者は検証中にアルゴリズム レベルでアーティファクトを検出できます。たとえば、署名自体が、ハイブリッド署名方式が使用されているという情報をエンコードする場合があります。このタイプの例は [HYBRIDSIGDESIGN] にあります。
For schemes achieving the most demanding security notion, Strong Non-Separability with Simultaneous Verification, verification succeeds only when both of the component signatures are present and the verifier has verified both signatures. Moreover, no information is leaked to the receiver during the verification process on the possible validity of the component signatures until both verify (or verification failure may or may not be attributable to a specific component algorithm). This construct most closely mirrors traditional digital signatures where, assuming that the verifier does verify a signature at all, the result is either a positive verification of the full signature or a failure if the signature is not valid. For fused hybrid signatures, a full signature implies the fusion of both component algorithms; therefore, this type of construction has the potential to achieve the strongest non-separability notion, which ensures an all-or-nothing approach to verification, regardless of adversarial action. Examples of algorithms providing this type of security can be found in [HYBRIDSIGDESIGN].
最も要求の厳しいセキュリティ概念である同時検証による強力な非分離性を実現するスキームの場合、両方のコンポーネントの署名が存在し、検証者が両方の署名を検証した場合にのみ検証が成功します。さらに、両方が検証するまで（または検証の失敗が特定のコンポーネントのアルゴリズムに起因する場合もそうでない場合もある）、検証プロセス中にコンポーネント署名の有効性の可能性に関する情報が受信機に漏洩することはありません。この構造は従来のデジタル署名を最もよく反映しており、検証者が署名をまったく検証すると仮定すると、結果は完全な署名の肯定的な検証か、署名が有効でない場合の失敗のいずれかになります。融合ハイブリッド署名の場合、完全な署名は両方のコンポーネント アルゴリズムの融合を意味します。したがって、このタイプの構造は、敵対的な行動に関係なく、検証に対する全か無かのアプローチを保証する最も強力な非分離性の概念を達成する可能性があります。このタイプのセキュリティを提供するアルゴリズムの例は、[HYBRIDSIGDESIGN] にあります。
Hybridization benefits from the presence of artifacts as evidence of the sender's intent to decrease the risk of successful stripping attacks. This, however, depends strongly on where such evidence resides (e.g., in the message, in the signature, or somewhere on the protocol level instead of at the algorithmic level). Even commonly discussed hybrid approaches, such as concatenation, are not inherently tied to one type of security (e.g., WNS or SNS). This can lead to ambiguities when comparing different approaches and assumptions about security or lack thereof. Thus, in this section, we cover artifact locations and also walk through a high-level comparison of a few hybrid categories to show how artifact location can differ within a given approach. Artifact location is tied to non-separability notions as described above; thus, the selection of a given security guarantee and general hybrid approach must also include a finer-grained selection of artifact placement.
ハイブリダイゼーションは、ストリッピング攻撃が成功するリスクを軽減するという送信者の意図の証拠としてアーティファクトの存在から恩恵を受けます。ただし、これは、そのような証拠がどこに存在するか (メッセージ内、署名内、またはアルゴリズム レベルではなくプロトコル レベルのどこか) に大きく依存します。連結などの一般的に議論されているハイブリッド アプローチでさえ、本質的に 1 つの種類のセキュリティ (WNS や SNS など) に結び付けられているわけではありません。これにより、セキュリティまたはセキュリティの欠如に関するさまざまなアプローチや前提を比較する際に曖昧さが生じる可能性があります。したがって、このセクションでは、アーティファクトの位置について説明し、いくつかのハイブリッド カテゴリの概要を比較して、特定のアプローチ内でアーティファクトの位置がどのように異なるかを示します。アーティファクトの位置は、上で説明したように非分離性の概念に関連付けられています。したがって、特定のセキュリティ保証と一般的なハイブリッド アプローチの選択には、アーティファクトの配置のより詳細な選択も含める必要があります。
Note that non-separability is a security notion of the signature scheme and not directly related to artifacts -- however, artifacts may be used for detection of separation. For instance, under strong non-separability, the scheme would fail verification if separation occurs, while for weak non-separability, some artifacts exist if separation occurs but verification would not necessarily fail. The verifier could indeed ignore the artifact, resulting in the scheme achieving only weak non-separability and not strong non-separability. However, the artifact exists and could be identified if an investigation occurred. Under weak non-separability, detection of separation may depend on non-cryptographic configurations or other dependencies. Also, strong non-separability and weak non-separability are properties of the signature scheme -- artifacts are not necessarily in the signature and may appear in the signed message, certificate, protocol, or policy (hence them not necessarily being related to the strong non-separability and weak non-separability security notions). Artifacts may still be useful (albeit dependent on system configurations) even if separable signatures are used.
非分離性は署名スキームのセキュリティ概念であり、アーティファクトとは直接関係しないことに注意してください。ただし、アーティファクトは分離の検出に使用される可能性があります。たとえば、強い非分離性では、分離が発生するとスキームは検証に失敗しますが、弱い非分離性では、分離が発生するといくつかのアーティファクトが存在しますが、検証は必ずしも失敗するとは限りません。実際、検証者はアーティファクトを無視する可能性があり、その結果、スキームは弱い非分離性のみを達成し、強い非分離性は達成できません。ただし、アーティファクトは存在しており、調査が行われれば特定される可能性があります。弱い非分離性の下では、分離の検出は非暗号化構成または他の依存関係に依存する可能性があります。また、強い非分離性と弱い非分離性は署名スキームの特性です。アーティファクトは必ずしも署名に含まれるわけではなく、署名されたメッセージ、証明書、プロトコル、またはポリシーに現れる可能性があります (したがって、それらは必ずしも強い非分離性と弱い非分離性のセキュリティ概念に関連しているわけではありません)。分離可能な署名が使用されている場合でも、アーティファクトは (システム構成に依存しますが) 引き続き役立つ場合があります。
There are a variety of artifact locations possible, ranging from within the message to the signature algorithm to the protocol level 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 label artifact. Depending on the hybrid type, it might be possible to strip this away. For example, a quantum attacker could strip away the post-quantum signature of a concatenated dual signature, and, being able to forge the traditional signature, it could remove the label artifact from the message as well. So, for many applications and threat models, adding an artifact in the message might be insufficient under stripping attacks. Another artifact location 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 attack occurs. In yet another case, artifacts may be present through the fused hybrid method, thus making them part of the signature at the algorithmic level. Note that in this latter case, it is not possible for an adversary to strip one of the component signatures or use a component of the hybrid signature to create a forgery for a component algorithm. Such signatures provide SNS. Consequently, this also implies that the artifacts of hybridization are absolute in that verification failure would occur if an adversary tries to remove them.
表 1 に示すように、メッセージ内から署名アルゴリズム、プロトコル レベル、さらにはポリシーに至るまで、さまざまなアーティファクトの場所が考えられます。たとえば、1 つのアーティファクトの場所が、署名されるメッセージ内にある可能性があります (ラベル アーティファクトを含むなど)。ハイブリッドタイプによっては、これを取り除くことができる場合があります。たとえば、量子攻撃者は、連結された二重署名の量子後署名を剥奪し、従来の署名を偽造できるため、メッセージからラベル アーティファクトも削除する可能性があります。したがって、多くのアプリケーションや脅威モデルでは、メッセージにアーティファクトを追加するだけではストリッピング攻撃では不十分である可能性があります。[COMP-MLDSA] で説明されているように、別のアーティファクトの場所が公開鍵証明書内にある可能性があります。このような場合、ストリッピング攻撃が発生した場合でも、アーティファクトは依然として存在します。さらに別のケースでは、融合ハイブリッド法によってアーティファクトが存在する可能性があり、その結果、アーティファクトがアルゴリズム レベルで署名の一部となる場合があります。後者の場合、攻撃者がコンポーネント署名の 1 つを剥奪したり、ハイブリッド署名のコンポーネントを使用してコンポーネント アルゴリズムの偽造を作成したりすることは不可能であることに注意してください。このような署名がSNSを提供します。したがって、これは、敵対者がそれらを削除しようとすると検証失敗が発生するという点で、ハイブリダイゼーションのアーティファクトが絶対的なものであることも意味します。
Eventual security analysis may be a consideration in choosing between levels. For example, if the security of the hybrid scheme is dependent on system policy, then cryptographic analysis must necessarily be reliant on specific policies, and it may not be possible to describe a scheme's security in a standalone sense. In this case, it is necessary to consider the configuration of a particular implementation or use to assess security, which could increase the risk of unknown and unanticipated vulnerabilities, regardless of the algorithms in use.
レベルを選択する際には、最終的なセキュリティ分析を考慮する必要があります。たとえば、ハイブリッド スキームのセキュリティがシステム ポリシーに依存する場合、暗号解析は必然的に特定のポリシーに依存する必要があり、スタンドアロンの意味でスキームのセキュリティを説明することはできない可能性があります。この場合、セキュリティを評価するために特定の実装または使用の構成を考慮する必要があります。これにより、使用されているアルゴリズムに関係なく、未知の予期しない脆弱性のリスクが高まる可能性があります。
+========================================+===========+
| Location of Artifacts of Hybrid Intent | Level |
+========================================+===========+
| Signature | Algorithm |
+----------------------------------------+-----------+
| Certificate | Protocol |
+----------------------------------------+-----------+
| Algorithm agreement / negotiation | Protocol |
+----------------------------------------+-----------+
| Message | Policy |
+----------------------------------------+-----------+
Table 1: Artifact Placement Levels
表 1: アーティファクトの配置レベル
Here we provide a high-level example of how artifacts can appear in different locations even within a single, common approach. We look at the following categories of approaches: concatenation, nesting, and fusion. This is to illustrate that a given approach does not inherently imply a specific non-separability notion and that there are subtleties to the selection decision, since hybrid artifacts are related to non-separability guarantees. Additionally, this comparison highlights how artifact placement can be identical in two different hybrid approaches.
ここでは、単一の一般的なアプローチ内であっても、アーティファクトがさまざまな場所にどのように表示されるかを示す高レベルの例を示します。ここでは、連結、ネスティング、融合といったアプローチのカテゴリーを検討します。これは、特定のアプローチが本質的に特定の非分離性の概念を意味するものではなく、ハイブリッド アーティファクトが非分離性の保証に関連しているため、選択の決定には微妙な点があることを示しています。さらに、この比較は、2 つの異なるハイブリッド アプローチでアーティファクトの配置がどのように同一になるかを強調しています。
We briefly summarize the hybrid approach categories (concatenation, nesting, and fusion) for clarity in description before showing how each one may have artifacts in different locations in Table 2.
説明をわかりやすくするために、ハイブリッド アプローチのカテゴリ (連結、ネスト、融合) を簡単にまとめてから、表 2 のさまざまな場所にそれぞれのアプローチのアーチファクトがどのように発生するかを示します。
* Concatenation: Variants of hybridization where, for component algorithms Sigma_1.Sign and Sigma_2.Sign, the hybrid signature is calculated as a concatenation (sig_1, sig_2) such that sig_1 = Sigma_1.Sign(hybridAlgID || m) and sig_2 = Sigma_2.Sign(hybridAlgID || m).
* 連結: コンポーネント アルゴリズム Sigma_1.Sign および Sigma_2.Sign の場合、ハイブリッド署名は sig_1 = Sigma_1.Sign(hybridAlgID || m) および sig_2 = Sigma_2.Sign(hybridAlgID || m) となる連結 (sig_1, sig_2) として計算されます。
* Nesting: Variants of hybridization where, for component algorithms 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 = Sigma_1.Sign(hybridAlgID || m) and sig_2 = Sigma_2.Sign(hybridAlgID || (m || sig_1)).
* ネスティング: コンポーネント アルゴリズム Sigma_1.Sign および Sigma_2.Sign の場合、ハイブリッド署名は階層化アプローチで (sig_1, sig_2) として計算されます。たとえば、 sig_1 = Sigma_1.Sign(hybridAlgID || m) および sig_2 = Sigma_2.Sign(hybridAlgID || (m)|| sig_1))。
* Fused hybrid: Variants of hybridization, where for component algorithms Sigma_1.Sign and Sigma_2.Sign, the hybrid signature is calculated to generate a single hybrid signature sig_h that cannot be cleanly separated to form one or more valid component constructs. For example, if both signature schemes are constructed through the Fiat-Shamir transform, the component 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 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 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 does not belong to either of the component signatures but rather both, meaning that the signatures are 'entangled'.
* 融合ハイブリッド: ハイブリダイゼーションの変形。コンポーネント アルゴリズム Sigma_1.Sign および Sigma_2.Sign の場合、ハイブリッド署名は、1 つ以上の有効なコンポーネント構成を形成するためにきれいに分離できない単一のハイブリッド署名 sig_h を生成するように計算されます。たとえば、両方の署名スキームが Fiat-Shamir 変換を通じて構築されている場合、コンポーネントの署名には応答 r_1 と r_2 とチャレンジ c_1 と c_2 が含まれます。ここで、c_1 と c_2 は、それぞれのコミットメント comm_1 と comm_2 (およびメッセージ) に対して計算されたハッシュです。融合ハイブリッド署名は、コンポーネント応答 r_1 および r_2 と、両方のコミットメントのハッシュとして計算されるチャレンジ c、つまり c = Hash((comm_1 || comm_2) || Hash2(message)) で構成されます。したがって、 c はコンポーネント署名のどちらにも属さず、両方に属しており、署名が「絡み合っている」ことを意味します。
+====+=========================+==================================+
| # | Location of Artifacts | Category |
| | of Hybrid Intent | |
+====+=========================+==================================+
| | | *Concatenated* |
+----+-------------------------+==================================+
| 1 | None | No label in message, public keys |
| | | are in separate certificates |
+----+-------------------------+----------------------------------+
| 2 | In message | Label in message, public keys |
| | | are in separate certificates |
+----+-------------------------+----------------------------------+
| 3 | In certificate | No label in message, public keys |
| | | are in combined certificate |
+----+-------------------------+----------------------------------+
| 4 | In message and | Label in message, public keys |
| | certificate | are in combined certificate |
+----+-------------------------+==================================+
| | | *Nested* |
+----+-------------------------+==================================+
| 5 | In message | Label in message, public keys |
| | | are in separate certificates |
+----+-------------------------+----------------------------------+
| 6 | In certificate | No label in message, public keys |
| | | are in combined certificate |
+----+-------------------------+----------------------------------+
| 7 | In message and | Label in message, public keys |
| | certificate | are in combined certificate |
+----+-------------------------+==================================+
| | | *Fused* |
+----+-------------------------+==================================+
| 8 | In signature | Public keys are in separate |
| | | certificates |
+----+-------------------------+----------------------------------+
| 9 | In signature and | Label in message, public keys |
| | message | are in separate certificates |
+----+-------------------------+----------------------------------+
| 10 | In signature and | Public keys are in combined |
| | certificate | certificate |
+----+-------------------------+----------------------------------+
| 11 | In signature and | Label in message, public keys |
| | message and certificate | are in combined certificate |
+----+-------------------------+----------------------------------+
Table 2: Artifact Locations Depending on the Hybrid Signature Type
表 2: ハイブリッド署名タイプに応じたアーティファクトの場所
As shown in Table 2, while concatenation may appear to refer to a single type of combiner, there are in fact several possible artifact locations depending on implementation choices. Artifacts help to support detection in the case of stripping attacks, which means that different artifact locations imply different overall system implementation considerations to be able to achieve such detection.
表 2 に示すように、連結は単一タイプの結合器を指すように見えますが、実際には、実装の選択に応じて、考えられるアーティファクトの場所がいくつかあります。アーティファクトは、ストリッピング攻撃の場合の検出をサポートするのに役立ちます。これは、アーティファクトの場所が異なると、そのような検出を実現するためにシステム全体の実装に関する考慮事項が異なることを意味します。
Case 1 provides the weakest guarantees of hybrid identification, as there are no prescribed artifacts and therefore non-separability is not achieved. However, this does not imply that every implementation using concatenation fails to achieve non-separability. Thus, it is advisable for implementers to be transparent about artifact locations.
ケース 1 では、規定のアーティファクトがないため、非分離性が達成されないため、ハイブリッド識別の保証が最も弱くなります。ただし、これは、連結を使用するすべての実装が非分離性を達成できないことを意味するわけではありません。したがって、実装者はアーティファクトの場所について透明性を保つことが望ましいです。
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 the signature, and the artifact location means that the signature in turn relies on the authentic content of the message (the artifact label). This creates a risk of circular dependency. Alternative approaches, such as cases 3, 4, 6, and 7, solve this circular dependency by provisioning keys in a combined certificate.
ケース 2 と 5 では、アーティファクトはメッセージ内に存在します。これは、メッセージの信頼性が署名の有効性に依存し、アーティファクトの場所が、署名がメッセージの真正なコンテンツ (アーティファクト ラベル) に依存することを意味するため、注目に値します。これにより、循環依存のリスクが生じます。ケース 3、4、6、7 などの代替アプローチでは、結合された証明書でキーをプロビジョニングすることで、この循環依存関係を解決します。
Another observation from this comparison is that artifact locations may be similar among some approaches. For instance, cases 3 and 6 both contain artifacts in the certificate. Naturally, these are high-level examples and further specification on concrete schemes in the categories are needed before prescribing non-separability guarantees to each, but this does indicate how there could be a strong similarity between such guarantees. Such comparisons allow for a systematic decision process, where security is compared and identified, and if schemes are similar in the desired security goal, then decisions between schemes can be based on performance and implementation ease.
この比較からのもう 1 つの観察結果は、アーティファクトの位置がいくつかのアプローチ間で類似している可能性があるということです。たとえば、ケース 3 とケース 6 の両方には、証明書にアーティファクトが含まれています。当然のことながら、これらは高レベルの例であり、それぞれに非分離性の保証を規定する前に、カテゴリー内の具体的なスキームに関するさらなる仕様が必要ですが、これは、そのような保証の間にどのように強い類似性があり得るかを示しています。このような比較により、セキュリティを比較して特定する体系的な意思決定プロセスが可能になります。スキームが目的のセキュリティ目標において類似している場合、スキーム間の決定はパフォーマンスと実装の容易さに基づいて行うことができます。
A final observation that this type of comparison provides is how various combiners may change the security analysis assumptions in a system. For instance, cases 3, 4, 6, and 7 all push artifacts -- and therefore the signature validity -- into the certificate chain. Naturally, the entire chain must then also use a similar combiner if a straightforward security argument is to be made. Other cases, such as 8, 9, 10, and 11, put artifacts within the signature itself, meaning that these bear the closest resemblance to traditional schemes where message authenticity is dependent on signature validity.
このタイプの比較によって得られる最後の観察は、さまざまな結合器がシステム内のセキュリティ分析の前提をどのように変更する可能性があるかということです。たとえば、ケース 3、4、6、および 7 はすべて、アーティファクト、つまり署名の有効性を証明書チェーンにプッシュします。当然のことながら、直接的なセキュリティの議論を行う場合は、チェーン全体でも同様の結合器を使用する必要があります。8、9、10、11 などの他のケースでは、署名自体の中にアーティファクトが含まれています。これは、メッセージの信頼性が署名の有効性に依存する従来のスキームに最もよく似ていることを意味します。
In practice, use of hybrid digital signatures relies on standards where applicable. This is particularly relevant in the cases where use of FIPS-approved software modules is required but applies equally to any guidance or policy direction that specifies that at least one component algorithm of the hybrid scheme has passed some certification type while not specifying requirements on the other component. NIST provides the following guidance in [NIST_PQC_FAQ] (emphasis added):
実際には、ハイブリッド デジタル署名の使用は、該当する標準に依存します。これは、FIPS 承認のソフトウェア モジュールの使用が必要な場合に特に関連しますが、ハイブリッド スキームの少なくとも 1 つのコンポーネント アルゴリズムがある認証タイプに合格し、他のコンポーネントの要件を指定しないことを指定するガイダンスまたはポリシーの方向にも同様に当てはまります。NIST は、[NIST_PQC_FAQ] で次のガイダンスを提供しています (強調追加)。
Assume that in a [hybrid] signature, _one signature is generated with a NIST-approved signature scheme as specified in FIPS 186, while another signature(s) can be generated using different schemes_, e.g., ones that are not currently specified in NIST standards ... _[hybrid] signatures can be accommodated by current standards in "FIPS mode", as defined in FIPS 140, provided at least one of the component methods is a properly implemented, NIST-approved signature algorithm_. For the purposes of FIPS 140 validation, any signature that is generated by a non-approved component scheme would not be considered a security function, since the NIST-approved component is regarded as assuring the validity of the [hybrid] signature.
[ハイブリッド] 署名では、_1 つの署名は FIPS 186 で指定されている NIST 承認の署名スキームで生成され、別の署名は別のスキーム、たとえば現在 NIST 標準で指定されていないスキームを使用して生成できると仮定します。_ [ハイブリッド] 署名は、コンポーネント メソッドの少なくとも 1 つが適切に設定されていれば、FIPS 140 で定義されている「FIPS モード」の現在の標準に対応できます。実装された、NIST 承認の署名アルゴリズム_。FIPS 140 検証の目的では、NIST 承認コンポーネントは [ハイブリッド] 署名の有効性を保証するとみなされるため、承認されていないコンポーネント スキームによって生成された署名はセキュリティ機能とみなされません。
This document does not define a formal interpretation of the NIST statement; however, we use it as motivation to highlight some points that implementers of hybrid signature schemes may wish to consider when following any guidance documents that specify that 1) the signature scheme for one of the component algorithms must be approved and 2) the said algorithm must be a well-implemented or certified implementation. This type of need for approval (i.e., a requirement that an implementer is looking to follow regarding approval or certification of the software module implementation of a hybrid or its component algorithms) can drive some logistical decisions on what types of hybrid signature schemes an implementer should consider.
この文書は、NIST ステートメントの正式な解釈を定義するものではありません。ただし、これを動機として、ハイブリッド署名スキームの実装者が、1) コンポーネント アルゴリズムの 1 つの署名スキームが承認されなければならないこと、2) 当該アルゴリズムが適切に実装されているか、認定された実装である必要があることを指定するガイダンス文書に従うときに、考慮すべきいくつかの点を強調する動機として使用します。このタイプの承認の必要性 (つまり、ハイブリッドまたはそのコンポーネント アルゴリズムのソフトウェア モジュール実装の承認または認証に関して実装者が従うことを求めている要件) は、実装者がどのタイプのハイブリッド署名スキームを考慮する必要があるかについての論理的な決定を促進する可能性があります。
In this respect, there is a spectrum of approval that developers may consider as to whether they are using at least one approved component algorithm implementation (1-out-of-n approved software module) or whether every component algorithm implementation is individually approved (all approved software module).
この点において、開発者が少なくとも 1 つの承認済みコンポーネント アルゴリズム実装を使用しているか (n 個中 1 個の承認済みソフトウェア モジュール)、すべてのコンポーネント アルゴリズム実装が個別に承認されているのか (すべて承認済みソフトウェア モジュール) について、開発者が考慮する承認の範囲があります。
We provide a spectrum for the different nuances of approval of the hybrid combiners, where "approval" means that a software implementation of a component algorithm can be used unmodified for creation of the hybrid signature. This may be related to whether a hybrid combiner is likely to need dedicated certification.
ハイブリッド コンバイナーの承認のさまざまなニュアンスの範囲を提供します。ここで、「承認」とは、コンポーネント アルゴリズムのソフトウェア実装を変更せずにハイブリッド署名の作成に使用できることを意味します。これは、ハイブリッド コンバイナーに専用の認証が必要かどうかに関係している可能性があります。
| ---------------------------------------------------------|
| *New Algorithm*
|
| New signature scheme based on a selection of hardness
| assumptions.
|
| Separate approval needed.
| ---------------------------------------------------------|
| *No Approved Software Module*
|
| Hybrid combiner supports security analysis that can be
| reduced to approved component algorithms, potentially
| changing the component implementations.
|
| Uncertainty about whether separate approval is needed.
| ---------------------------------------------------------|
| *1-out-of-n Approved Software Module*
|
| Combiner supports one component algorithm and
| implementation in a black-box way but potentially
| changes the other component algorithm implementation(s).
|
| No new approval needed if the black-box component
| (implementation) is approved.
| ---------------------------------------------------------|
| *All Approved Software Modules*
|
| Hybrid combiner acts as a wrapper, fully independent of
| the component signature scheme implementations.
|
| No new approval needed if at least one component
| implementation is approved.
| ---------------------------------------------------------|
V
Figure 2: Need for Approval Spectrum
図 2: 承認スペクトルの必要性
The first listed "combiner" would be a new construction with a security reduction to different hardness assumptions but not necessarily to approved (or even existing) signature schemes. Such a new, singular algorithm relies on both traditional and next-generation principles.
最初にリストされている「コンバイナー」は、さまざまな硬度の仮定にセキュリティを削減する新しい構造ですが、必ずしも承認された (または既存の) 署名スキームに準拠する必要はありません。このような新しい特異なアルゴリズムは、従来の原理と次世代の原理の両方に依存しています。
Next is a combiner that might take inspiration from existing/approved signature schemes such that its security can be reduced to the security of the approved algorithms. The combiner may, however, alter the implementations. As such, it is uncertain whether new approval would be needed as it might depend on the combiner and changes. Such a case may potentially imply a distinction between a need for fresh approval of the algorithm(s) and approval of the implementation(s).
次は、既存の/承認された署名スキームからインスピレーションを得て、そのセキュリティを承認されたアルゴリズムのセキュリティにまで低減できるコンバイナーです。ただし、結合器は実装を変更する可能性があります。そのため、コンバイナーや変更内容に依存する可能性があるため、新たな承認が必要かどうかは不明です。このような場合は、アルゴリズムの新たな承認の必要性と実装の承認の必要性が区別される可能性があります。
The 1-out-of-n combiner uses at least one approved algorithm implementation in a black-box way (i.e., without modification to the software module implementation for that algorithm). It may potentially change the specifics of the other component algorithm implementations. If the premise is that no new approval is needed so long as at least one component is approved, then this is likely considered sufficient.
1-out-of-n 結合器は、ブラックボックス方式で (つまり、そのアルゴリズムのソフトウェア モジュール実装を変更せずに) 少なくとも 1 つの承認されたアルゴリズム実装を使用します。他のコンポーネントのアルゴリズム実装の詳細が変更される可能性があります。少なくとも 1 つのコンポーネントが承認されている限り、新たな承認は必要ないという前提であれば、おそらくこれで十分であると考えられます。
In an all-approved combiner, every algorithm implementation is used in a black-box way. A concatenation combiner is a simple example (where a signature is valid if all component signatures are valid). Thus, as all algorithm implementations are approved, a requirement that at least one of hybrid component algorithms is approved would be satisfied.
すべて承認された結合器では、すべてのアルゴリズム実装がブラックボックス方式で使用されます。連結結合器は単純な例です (すべてのコンポーネントの署名が有効であれば署名も有効です)。したがって、すべてのアルゴリズム実装が承認されると、ハイブリッド コンポーネント アルゴリズムの少なくとも 1 つが承認されるという要件が満たされます。
Unforgeability properties for hybrid signature schemes are more nuanced than for single-algorithm schemes.
ハイブリッド署名方式の偽造不可能性の特性は、単一アルゴリズム方式よりも微妙です。
Under the traditional EUF-CMA security assumption, an adversary requests signatures for messages of their choosing and succeeds if 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 hybrid signature scheme in the same way as single-algorithm schemes. Namely, the most straightforward extension of the traditional EUF-CMA security game would be that an adversary requests hybrid signatures 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 an earlier request. However, this has several layers of nuance under a hybrid construct.
従来の EUF-CMA セキュリティの前提では、攻撃者は選択したメッセージの署名を要求し、以前の要求の一部ではなかったメッセージの有効な署名を生成できれば成功します。EUF-CMA は、単一アルゴリズム方式と同じようにハイブリッド署名方式に適用されると考えることができます。つまり、従来の EUF-CMA セキュリティ ゲームの最も単純な拡張は、攻撃者が選択したメッセージのハイブリッド署名を要求し、以前のリクエストの一部ではなかったメッセージの有効なハイブリッド署名を生成できれば成功するというものです。ただし、ハイブリッド構造では、これにはいくつかの層のニュアンスがあります。
Consider, for example, a simplistic hybrid approach using concatenated component algorithms. If the hybrid signature is stripped, such that a single component signature is submitted to a verification algorithm for that component along with the message that was signed by the hybrid signature scheme, the result would be an EUF-CMA forgery for the component signature. This is because as the component signing algorithm was not previously called for the message, the hybrid signing algorithm was used to generate the signature. This is an example of a component algorithm forgery, which may lead to a cross-algorithm attack or cross-protocol attack.
たとえば、連結コンポーネント アルゴリズムを使用した単純化されたハイブリッド アプローチを考えてみましょう。If the hybrid signature is stripped, such that a single component signature is submitted to a verification algorithm for that component along with the message that was signed by the hybrid signature scheme, the result would be an EUF-CMA forgery for the component signature.これは、メッセージに対してコンポーネント署名アルゴリズムが以前に呼び出されなかったため、署名の生成にハイブリッド署名アルゴリズムが使用されたためです。これはコンポーネント アルゴリズムの偽造の一例であり、クロスアルゴリズム攻撃またはクロスプロトコル攻撃につながる可能性があります。
The component algorithm forgery verifier target does not need to be the intended recipient of the hybrid-signed message and may even be in an entirely different system. This vulnerability is particularly an issue among concatenated or nested hybrid signature schemes where individual component verification could be possible. It should be noted that policy enforcement of a hybrid verification does not mitigate the issue on the intended message recipient: The component algorithm forgery could occur on any system that accepts the component keys.
コンポーネント アルゴリズム偽造検証者のターゲットは、ハイブリッド署名メッセージの意図した受信者である必要はなく、まったく異なるシステムに存在する場合もあります。この脆弱性は、個々のコンポーネントの検証が可能な連結またはネストされたハイブリッド署名方式の間で特に問題となります。ハイブリッド検証のポリシー適用は、対象となるメッセージ受信者の問題を軽減するものではないことに注意してください。コンポーネント アルゴリズムの偽造は、コンポーネント キーを受け入れるどのシステムでも発生する可能性があります。
Informally stated, EUF-CMA security assumes that an adversary is able to request signatures on messages of their choosing and succeeds if they are able to produce a valid signature for a message that was not part of an earlier request. Thus, the corresponding EUF-CMA security for hybrids can be defined such that an adversary can request hybrid signatures 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 an earlier request. To meet this security guarantee, implicit requirements must hold. Namely, either component algorithm forgeries (and cross-protocol attacks) must be impossible in the use case or the hybrid signature choice must be strongly non-separable. Otherwise, component algorithm forgeries 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.
非公式に言えば、EUF-CMA セキュリティは、攻撃者が選択したメッセージの署名を要求でき、以前の要求の一部ではなかったメッセージの有効な署名を生成できれば成功することを前提としています。したがって、ハイブリッドに対応する EUF-CMA セキュリティは、攻撃者が選択したメッセージのハイブリッド署名を要求でき、以前の要求の一部ではなかったメッセージの有効なハイブリッド署名を生成できれば成功するように定義できます。このセキュリティ保証を満たすには、暗黙の要件が満たされている必要があります。つまり、コンポーネント アルゴリズムの偽造 (およびクロスプロトコル攻撃) がユースケースで不可能であるか、ハイブリッド署名の選択が強力に分離不可能である必要があります。それ以外の場合、コンポーネント アルゴリズムの偽造は、提供される EUF-CMA プロパティの種類に影響を与えるため、システム設計者や管理者がユースケースに合わせてハイブリッド アプローチを選択する際に注意すべき実際的な考慮事項です。
There are a couple approaches to alleviating this issue, as noted above. One is on restricting key reuse. As described in [COMP-MLDSA], prohibiting hybrid algorithm and component algorithm signers and verifiers from using the same keys can help ensure that a component verifier cannot be tricked into verifying the hybrid signature. This would effectively put component algorithm forgeries out of scope for a use case. One means for restricting key reuse is through allowed key use descriptions in certificates. While prohibiting key reuse reduces the risk of such component algorithm forgeries, and is the mitigation described in [COMP-MLDSA], it is still a policy requirement and not a cryptographic assurance. Component algorithm forgery attacks may be possible if the policy is not followed or is followed inconsistently across all entities that might verify signatures using those keys. This needs to be accounted for in any security analysis. Since cryptographic provable security modeling has not historically accounted for key reuse in this way, it should not be assumed that systems with existing analyses are robust to this issue.
上で述べたように、この問題を軽減するにはいくつかのアプローチがあります。1 つはキーの再利用の制限です。[COMP-MLDSA] で説明されているように、ハイブリッド アルゴリズムとコンポーネント アルゴリズムの署名者と検証者が同じ鍵を使用することを禁止すると、コンポーネント検証者が騙されてハイブリッド署名を検証できないようにすることができます。これにより、コンポーネント アルゴリズムの偽造は事実上、ユースケースの範囲外になります。キーの再利用を制限する 1 つの手段は、証明書で許可されたキーの使用の説明を使用することです。鍵の再利用を禁止すると、そのようなコンポーネント アルゴリズムの偽造のリスクが軽減され、[COMP-MLDSA] で説明されている緩和策ですが、依然としてポリシー要件であり、暗号化の保証ではありません。ポリシーが守られていない場合、またはこれらのキーを使用して署名を検証する可能性のあるすべてのエンティティにわたって方針が一貫していない場合、コンポーネント アルゴリズムの偽造攻撃が発生する可能性があります。セキュリティ分析では、これを考慮する必要があります。暗号による証明可能なセキュリティ モデリングでは、これまでこのようなキーの再利用が考慮されていなかったため、既存の分析を備えたシステムがこの問題に対して堅牢であると想定すべきではありません。
The other approach noted for alleviating the component algorithm forgery risk is through hybrid signature selection of a scheme that provides strong non-separability. Under this approach, the hybrid signature cannot be separated into component algorithm signatures that will verify correctly, thereby preventing the signature separation required for the component algorithm forgery attack to be successful.
コンポーネント アルゴリズムの偽造リスクを軽減するために注目されているもう 1 つのアプローチは、強力な非分離性を提供するスキームのハイブリッド署名選択によるものです。このアプローチでは、ハイブリッド署名を正しく検証するコンポーネント アルゴリズム署名に分離することができないため、コンポーネント アルゴリズム偽造攻撃を成功させるために必要な署名の分離が妨げられます。
It should be noted that weak non-separability is insufficient for mitigating risks of component algorithm forgeries. As noted in Section 9.3 of [COMP-MLDSA], in cases of hybrid algorithm selection that provide only weak non-separability, key reuse should be avoided, as mentioned above, to mitigate risks of introducing EUF-CMA vulnerabilities for component algorithms.
弱い非分離性では、コンポーネントアルゴリズム偽造のリスクを軽減するには不十分であることに注意してください。[COMP-MLDSA] のセクション 9.3 に記載されているように、弱い非分離性のみを提供するハイブリッド アルゴリズムを選択する場合、コンポーネント アルゴリズムに EUF-CMA 脆弱性が導入されるリスクを軽減するために、前述のようにキーの再利用は避けるべきです。
The design (and hence security guarantees) of hybrid signature schemes depend heavily on the properties needed for the application or protocol using hybrid signatures. It seems that not all goals can be achieved simultaneously as exemplified below.
ハイブリッド署名スキームの設計 (したがってセキュリティの保証) は、ハイブリッド署名を使用するアプリケーションまたはプロトコルに必要なプロパティに大きく依存します。以下に例示するように、すべての目標を同時に達成できるわけではないようです。
There is an inherent mutual exclusion between backwards compatibility and SNS. While WNS allows for a valid separation under leftover artifacts, SNS will ensure verification failure if a receiver attempts separation.
下位互換性と SNS の間には本質的に相互排他関係があります。WNS では、残されたアーティファクトの下で有効な分離が可能ですが、SNS では、受信者が分離を試みた場合に検証が失敗することが保証されます。
Similarly, there is an inherent mutual exclusion between backwards compatibility, when acted upon, and hybrid unforgeability, as briefly mentioned above. Since the goal of backwards compatibility is usually to allow legacy systems without any software change to be able to process hybrid signatures, all differences between the legacy signature format and the hybrid signature format must be allowed to be ignored, including skipping verification of signatures in addition to the classical signature. As such, if a system does skip a component signature, security does not rely on the security of all component signatures. Note that this mutual exclusion occurs at the verification stage, as a hybrid signature that is verified by a system that can process both component schemes can provide hybrid unforgeability even if another (legacy) system, processing the same hybrid signature, loses that property.
同様に、上で簡単に説明したように、下位互換性とハイブリッドの非偽造可能性の間には、本質的な相互排除が存在します。下位互換性の目標は、通常、ソフトウェアを変更することなくレガシー システムがハイブリッド署名を処理できるようにすることであるため、従来の署名に加えて署名の検証をスキップするなど、レガシー署名形式とハイブリッド署名形式の間のすべての違いは無視できるようにする必要があります。したがって、システムがコンポーネント署名をスキップした場合、セキュリティはすべてのコンポーネント署名のセキュリティに依存しません。この相互排他は検証段階で発生することに注意してください。両方のコンポーネント スキームを処理できるシステムによって検証されるハイブリッド署名は、同じハイブリッド署名を処理する別の (レガシー) システムがその特性を失った場合でも、ハイブリッドの偽造不可能性を提供できるためです。
Hybrid algorithms that achieve simultaneous verification tend to fuse (or 'entangle') the verification of component algorithms such that verification operations from the different component schemes depend on each other in some way. Consequently, there may be a natural connection between achieving simultaneous verification and a higher need for approval. As a contrasting example, NIST accommodates concatenation of a FIPS-approved signature and another (potentially non-FIPS approved) signature without any artifacts in FIPS 140 validation [NIST_PQC_FAQ]; however, as the component signatures are verified separately, it is not possible to enforce 'simultaneous verification'.
同時検証を実現するハイブリッド アルゴリズムは、異なるコンポーネント スキームからの検証操作が何らかの形で相互に依存するように、コンポーネント アルゴリズムの検証を融合する (または「絡ませる」) 傾向があります。したがって、同時検証の達成と承認欲求の高まりとの間には自然な関係がある可能性があります。対照的な例として、NIST は、FIPS 140 検証でアーティファクトを発生させることなく、FIPS 承認の署名と別の (FIPS 非承認の可能性がある) 署名の連結に対応しています [NIST_PQC_FAQ]。ただし、コンポーネントの署名は個別に検証されるため、「同時検証」を強制することはできません。
This document discusses digital signature constructions that may be used in security protocols. It is an Informational document and does not directly affect any other documents. The security considerations for any specific implementation or incorporation of a hybrid scheme should be discussed in the relevant specification documents.
この文書では、セキュリティ プロトコルで使用できるデジタル署名の構造について説明します。これは情報文書であり、他の文書には直接影響しません。ハイブリッド方式の特定の実装または組み込みに関するセキュリティ上の考慮事項は、関連する仕様文書で議論する必要があります。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for
Post-Quantum Traditional Hybrid Schemes", RFC 9794,
DOI 10.17487/RFC9794, June 2025,
<https://www.rfc-editor.org/info/rfc9794>.
[RFC9954] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid Key
Exchange in TLS 1.3", RFC 9954, DOI 10.17487/RFC9954, July
2026, <https://www.rfc-editor.org/info/rfc9954>.
[COMP-MLDSA]
Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S.
Fluhrer, "Composite Module-Lattice-Based Digital Signature
Algorithm (ML-DSA) for use in X.509 Public Key
Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-lamps-pq-composite-sigs-19, 21 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-19>.
[EUFCMA] Green, M., "EUF-CMA and SUF-CMA",
<https://blog.cryptographyengineering.com/euf-cma-and-suf-
cma/>.
[FALCON] Fouque, P., Hoffstein, J., Kirchner, P., Lyubashevsky, V.,
Pornin, T., Prest, T., Ricosset, T., Seiler, G., Whyte,
W., and Z. Zhang, "FALCON: Fast-Fourier Lattice-based
Compact Signatures over NTRU", Specification v1.2, 10
January 2020, <https://falcon-sign.info/falcon.pdf>.
[FS] Fiat, A. and A. Shamir, "How To Prove Yourself: Practical
Solutions to Identification and Signature Problems",
Advances in Cryptology -- CRYPTO' 86, Lecture Notes in
Computer Science, vol. 263, pp. 186-194,
DOI 10.1007/3-540-47721-7_12, 1986,
<https://doi.org/10.1007%2F3-540-47721-7_12>.
[GEMSS] "GeMSS: A Great Multivariate Short Signature", 15 April
2020, <https://www-polsys.lip6.fr/Links/NIST/
GeMSS_specification_round2_V2.pdf>.
[HQC_CVE] NIST, "CVE-2024-54137: liboqs has a correctness error in
HQC decapsulation", 6 December 2024,
<https://nvd.nist.gov/vuln/detail/CVE-2024-54137>.
[HYBRIDSIG]
Bindel, N., Herath, U., McKague, M., and D. Stebila,
"Transitioning to a Quantum-Resistant Public Key
Infrastructure", Cryptology ePrint Archive, Paper
2017/460, May 2017, <https://eprint.iacr.org/2017/460>.
[HYBRIDSIGDESIGN]
Bindel, N. and B. Hale, "A Note on Hybrid Signature
Schemes", Cryptology ePrint Archive, Paper 2023/423, March
2023, <https://eprint.iacr.org/2023/423>.
[KYBERSLASH]
Bernstein, D. J., Bhargavan, K., Bhasin, S.,
Chattopadhyay, A., Chia, T. K., Kannwischer, M. J.,
Kiefer, F., Ravi, P., and G. Tamvada, "KyberSlash:
Exploiting secret-dependent division timings in Kyber
implementations", Cryptology ePrint Archive, Paper
2024/1049, June 2024, <https://eprint.iacr.org/2024/1049>.
[MLDSA] NIST, "Module-Lattice-Based Digital Signature Standard",
NIST FIPS 204, DOI 10.6028/NIST.FIPS.204, August 2024,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.204.pdf>.
[NC-HYBRID-AUTH]
Becker, A., Guthrie, R., and M. J. Jenkins, "Non-Composite
Hybrid Authentication in PKIX and Applications to Internet
Protocols", Work in Progress, Internet-Draft, draft-
becker-guthrie-noncomposite-hybrid-auth-00, 22 March 2022,
<https://datatracker.ietf.org/doc/html/draft-becker-
guthrie-noncomposite-hybrid-auth-00>.
[NIST_PQC_FAQ]
NIST, "Post-Quantum Cryptography FAQs", 5 July 2022,
<https://web.archive.org/web/20220705163944/
https://csrc.nist.gov/Projects/ post-quantum-cryptography/
faqs>.
[QRCSP] Bernstein, D. J., "Quantifying risks in cryptographic
selection processes", 24 November 2023,
<https://cr.yp.to/papers/qrcsp-20231124.pdf>.
[RAINBOW] "PQC Rainbow", <https://www.pqcrainbow.org/>.
[RSA] Rivest, R. L., Shamir, A., and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key
Cryptosystems", Communications of the ACM, vol. 21, no. 2,
pp. 120-126, DOI 10.1145/359340.359342,
<https://doi.org/10.1145/359340.359342>.
This document is based on the template used for [RFC9954].
この文書は、[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
この文書の推進に貢献し、有用な洞察や視点を提供し、この分野での活動を刺激してくれた以下の方々にアルファベット順で感謝の意を表します。バーンスタイン、スコット・フラーラー、ジョン・グレイ、フェリックス・ギュンター、セルジュ・ミスター、マイク・オウンズワース、マックス・パラ、ダグラス・ステビラ、ファルコ・ストレンツケ、ブレンダン・ゼンバー
Nina Bindel
SandboxAQ
Email: nina.bindel@sandboxaq.com
Britta Hale
Naval Postgraduate School
Email: britta.hale@nps.edu
Deirdre Connolly
SandboxAQ
Email: durumcrustulum@gmail.com
Florence Driscoll
UK National Cyber Security Centre
Email: flo.d@ncsc.gov.uk