rfc9980.original   rfc9980.txt 
Network Working Group S. Kousidis Internet Engineering Task Force (IETF) S. Kousidis
Internet-Draft BSI Request for Comments: 9980 BSI
Intended status: Standards Track J. Roth Category: Standards Track J. Roth
Expires: 17 July 2026 F. Strenzke ISSN: 2070-1721 F. Strenzke
MTG AG MTG AG
A. Wussler A. Wussler
Proton AG Proton AG
13 January 2026 May 2026
Post-Quantum Cryptography in OpenPGP Post-Quantum Cryptography in OpenPGP
draft-ietf-openpgp-pqc-17
Abstract Abstract
This document defines a post-quantum public key algorithm extension This document defines a post-quantum public key algorithm extension
for the OpenPGP protocol, extending RFC9580. Given the generally for the OpenPGP protocol, extending RFC 9580. Given the generally
assumed threat of a cryptographically relevant quantum computer, this assumed threat of a cryptographically relevant quantum computer, this
extension provides a basis for long-term secure OpenPGP signatures extension provides a basis for long-term secure OpenPGP signatures
and ciphertexts. Specifically, it defines composite public key and ciphertexts. Specifically, it defines composite public key
encryption based on ML-KEM (formerly CRYSTALS-Kyber), composite encryption based on ML-KEM (formerly CRYSTALS-Kyber), composite
public key signatures based on ML-DSA (formerly CRYSTALS-Dilithium), public key signatures based on ML-DSA (formerly CRYSTALS-Dilithium),
both in combination with elliptic curve cryptography, and SLH-DSA both in combination with Elliptic Curve Cryptography (ECC), and SLH-
(formerly SPHINCS+) as a standalone public key signature scheme. DSA (formerly SPHINCS+) as a standalone public key signature scheme.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/.
Discussion of this document takes place on the WG Working Group
mailing list (mailto:openpgp@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/openpgp/. Subscribe at
https://www.ietf.org/mailman/listinfo/openpgp/.
Source for this draft and an issue tracker can be found at
https://github.com/openpgp-pqc/draft-openpgp-pqc.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 17 July 2026. 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/rfc9980.
Copyright Notice Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction
1.1. Conventions used in this Document . . . . . . . . . . . . 6 1.1. Conventions Used In This Document
1.1.1. Terminology for Multi-Algorithm Schemes . . . . . . . 6 1.1.1. Terminology for Multi-Algorithm Schemes
1.2. Post-Quantum Cryptography . . . . . . . . . . . . . . . . 6 1.2. Post-Quantum Cryptography
1.2.1. ML-KEM . . . . . . . . . . . . . . . . . . . . . . . 7 1.2.1. ML-KEM
1.2.2. ML-DSA . . . . . . . . . . . . . . . . . . . . . . . 7 1.2.2. ML-DSA
1.2.3. SLH-DSA . . . . . . . . . . . . . . . . . . . . . . . 7 1.2.3. SLH-DSA
1.3. Elliptic Curve Cryptography . . . . . . . . . . . . . . . 7 1.3. Elliptic Curve Cryptography
1.4. Standalone and Multi-Algorithm Schemes . . . . . . . . . 7 1.4. Standalone and Multi-Algorithm Schemes
1.4.1. Standalone and Composite Multi-Algorithm Schemes . . 7 1.4.1. Standalone and Composite Multi-Algorithm Schemes
1.4.2. Non-Composite Algorithm Combinations . . . . . . . . 8 1.4.2. Non-Composite Algorithm Combinations
2. Supported Public Key Algorithms . . . . . . . . . . . . . . . 8 2. Supported Public Key Algorithms
2.1. Algorithm Specifications . . . . . . . . . . . . . . . . 8 2.1. Algorithm Specifications
3. Algorithm Combinations . . . . . . . . . . . . . . . . . . . 10 3. Algorithm Combinations
3.1. Composite KEMs . . . . . . . . . . . . . . . . . . . . . 10 3.1. Composite KEMs
3.2. Composite Signatures . . . . . . . . . . . . . . . . . . 10 3.2. Composite Signatures
3.3. Multiple Signatures . . . . . . . . . . . . . . . . . . . 10 3.3. Multiple Signatures
3.4. ECC Requirements . . . . . . . . . . . . . . . . . . . . 10 3.4. ECC Requirements
3.5. Key Version Binding . . . . . . . . . . . . . . . . . . . 11 3.5. Key Version Binding
4. Composite KEM Schemes . . . . . . . . . . . . . . . . . . . . 11 4. Composite KEM Schemes
4.1. Building Blocks . . . . . . . . . . . . . . . . . . . . . 11 4.1. Building Blocks
4.1.1. ECDH KEM . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. ECDH KEM
4.1.2. ML-KEM . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.2. ML-KEM
4.2. Composite Encryption Schemes with ML-KEM . . . . . . . . 14 4.2. Composite Encryption Schemes with ML-KEM
4.2.1. Key Combiner . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Key Combiner
4.2.2. Key Generation Procedure . . . . . . . . . . . . . . 15 4.2.2. Key Generation Procedure
4.2.3. Encryption Procedure . . . . . . . . . . . . . . . . 15 4.2.3. Encryption Procedure
4.2.4. Decryption Procedure . . . . . . . . . . . . . . . . 16 4.2.4. Decryption Procedure
4.3. Packet Specifications . . . . . . . . . . . . . . . . . . 17 4.3. Packet Specifications
4.3.1. Public Key Encrypted Session Key Packets (Packet Type 4.3.1. Public Key Encrypted Session Key Packets (Packet Type
ID 1) . . . . . . . . . . . . . . . . . . . . . . . . 17 ID 1)
4.3.2. Key Material Packets . . . . . . . . . . . . . . . . 18 4.3.2. Key Material Packets
5. Composite Signature Schemes . . . . . . . . . . . . . . . . . 19 5. Composite Signature Schemes
5.1. Building Blocks . . . . . . . . . . . . . . . . . . . . . 19 5.1. Building Blocks
5.1.1. EdDSA-Based Signatures . . . . . . . . . . . . . . . 19 5.1.1. EdDSA-Based Signatures
5.1.2. ML-DSA Signatures . . . . . . . . . . . . . . . . . . 19 5.1.2. ML-DSA Signatures
5.2. Composite Signature Schemes with ML-DSA . . . . . . . . . 20 5.2. Composite Signature Schemes with ML-DSA
5.2.1. Key Generation Procedure . . . . . . . . . . . . . . 20 5.2.1. Key Generation Procedure
5.2.2. Signature Generation . . . . . . . . . . . . . . . . 20 5.2.2. Signature Generation
5.2.3. Signature Verification . . . . . . . . . . . . . . . 21 5.2.3. Signature Verification
5.3. Packet Specifications . . . . . . . . . . . . . . . . . . 21 5.3. Packet Specifications
5.3.1. Signature Packet (Packet Type ID 2) . . . . . . . . . 21 5.3.1. Signature Packet (Packet Type ID 2)
5.3.2. Key Material Packets . . . . . . . . . . . . . . . . 22 5.3.2. Key Material Packets
6. SLH-DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. SLH-DSA
6.1. The SLH-DSA Algorithms . . . . . . . . . . . . . . . . . 22 6.1. The SLH-DSA Algorithms
6.1.1. Key Generation . . . . . . . . . . . . . . . . . . . 23 6.1.1. Key Generation
6.1.2. Signature Generation . . . . . . . . . . . . . . . . 23 6.1.2. Signature Generation
6.1.3. Signature Verification . . . . . . . . . . . . . . . 23 6.1.3. Signature Verification
6.2. Packet Specifications . . . . . . . . . . . . . . . . . . 23 6.2. Packet Specifications
6.2.1. Signature Packet (Packet Type ID 2) . . . . . . . . . 23 6.2.1. Signature Packet (Packet Type ID 2)
6.2.2. Key Material Packets . . . . . . . . . . . . . . . . 24 6.2.2. Key Material Packets
7. Notes on Algorithms . . . . . . . . . . . . . . . . . . . . . 24 7. Notes on Algorithms
7.1. Symmetric Algorithms for SEIPD Packets . . . . . . . . . 24 7.1. Symmetric Algorithms for SEIPD Packets
7.2. Hash Algorithms for Key Binding Signatures . . . . . . . 25 7.2. Hash Algorithms for Key Binding Signatures
8. Migration Considerations . . . . . . . . . . . . . . . . . . 25 8. Migration Considerations
8.1. Encrypting to Traditional and PQ(/T) Keys . . . . . . . . 25 8.1. Encrypting to Traditional and PQ(/T) Keys
8.2. Signing with Traditional and PQ(/T) Keys . . . . . . . . 25 8.2. Signing with Traditional and PQ(/T) Keys
8.3. Verifying with Traditional and PQ(/T) Keys . . . . . . . 26 8.3. Verifying with Traditional and PQ(/T) Keys
8.4. Generating PQ(/T) Keys . . . . . . . . . . . . . . . . . 26 8.4. Generating PQ(/T) Keys
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations
9.1. Security Aspects of Composite Signatures . . . . . . . . 26 9.1. Security Aspects of Composite Signatures
9.1.1. Preventing Signature Cross-Protocol Attacks . . . . . 27 9.1.1. Preventing Signature Cross-Protocol Attacks
9.2. Key Combiner . . . . . . . . . . . . . . . . . . . . . . 27 9.2. Key Combiner
9.2.1. Domain Separation and Context Binding . . . . . . . . 27 9.2.1. Domain Separation and Context Binding
9.3. ML-DSA and SLH-DSA Hedged Variants . . . . . . . . . . . 28 9.3. ML-DSA and SLH-DSA Hedged Variants
9.4. Minimum Digest Size for PQ(/T) Signatures . . . . . . . . 28 9.4. Minimum Digest Size for PQ(/T) Signatures
9.5. Symmetric Algorithms for SEIPD Packets . . . . . . . . . 28 9.5. Symmetric Algorithms for SEIPD Packets
9.6. Key Generation . . . . . . . . . . . . . . . . . . . . . 29 9.6. Key Generation
9.7. Random Number Generation and Seeding . . . . . . . . . . 29 9.7. Random Number Generation and Seeding
10. Additional Considerations . . . . . . . . . . . . . . . . . . 29 10. Additional Considerations
10.1. Performance Considerations for SLH-DSA . . . . . . . . . 29 10.1. Performance Considerations for SLH-DSA
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 11. IANA Considerations
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. References
12.1. draft-wussler-openpgp-pqc-01 . . . . . . . . . . . . . . 32 12.1. Normative References
12.2. draft-wussler-openpgp-pqc-02 . . . . . . . . . . . . . . 33 12.2. Informative References
12.3. draft-wussler-openpgp-pqc-03 . . . . . . . . . . . . . . 33 Appendix A. Test Vectors
12.4. draft-wussler-openpgp-pqc-04 . . . . . . . . . . . . . . 33 A.1. Sample v6 Ed25519 with ML-KEM-768+X25519 Data
12.5. draft-ietf-openpgp-pqc-00 . . . . . . . . . . . . . . . 33 A.1.1. Transferable Secret Key
12.6. draft-ietf-openpgp-pqc-01 . . . . . . . . . . . . . . . 33 A.1.2. Transferable Public Key
12.7. draft-ietf-openpgp-pqc-02 . . . . . . . . . . . . . . . 34 A.1.3. Encrypted and Signed Message
12.8. draft-ietf-openpgp-pqc-03 . . . . . . . . . . . . . . . 34 A.2. Sample v4 Ed25519 with ML-KEM-768+X25519 Data
12.9. draft-ietf-openpgp-pqc-04 . . . . . . . . . . . . . . . 34 A.2.1. Transferable Secret Key
12.10. draft-ietf-openpgp-pqc-05 . . . . . . . . . . . . . . . 34 A.2.2. Transferable Public Key
12.11. draft-ietf-openpgp-pqc-06 . . . . . . . . . . . . . . . 35 A.2.3. Encrypted and Signed SEIPD v1 Message
12.12. draft-ietf-openpgp-pqc-07 . . . . . . . . . . . . . . . 35 A.2.4. Encrypted and Signed SEIPD v2 Message
12.13. draft-ietf-openpgp-pqc-08 . . . . . . . . . . . . . . . 35 A.3. Sample ML-DSA-65+Ed25519 with ML-KEM-768+X25519 Data
12.14. draft-ietf-openpgp-pqc-09 . . . . . . . . . . . . . . . 35 A.3.1. Transferable Secret Key
12.15. draft-ietf-openpgp-pqc-10 . . . . . . . . . . . . . . . 35 A.3.2. Transferable Public Key
12.16. draft-ietf-openpgp-pqc-11 . . . . . . . . . . . . . . . 35 A.3.3. Encrypted and Signed Message
12.17. draft-ietf-openpgp-pqc-12 . . . . . . . . . . . . . . . 36 A.3.4. Detached Signature
12.18. draft-ietf-openpgp-pqc-13 . . . . . . . . . . . . . . . 36 A.4. Sample ML-DSA-87+Ed448 with ML-KEM-1024+X448 Data
12.19. draft-ietf-openpgp-pqc-14 . . . . . . . . . . . . . . . 36 A.4.1. Transferable Secret Key
12.20. draft-ietf-openpgp-pqc-15 . . . . . . . . . . . . . . . 36 A.4.2. Transferable Public Key
12.21. draft-ietf-openpgp-pqc-16 . . . . . . . . . . . . . . . 36 A.4.3. Encrypted and Signed Message
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 A.4.4. Detached Signature
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36 A.5. Sample SLH-DSA-SHAKE-128s with ML-KEM-768+X25519 Data
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 A.5.1. Transferable Secret Key
Normative References . . . . . . . . . . . . . . . . . . . . . 36 A.5.2. Transferable Public Key
Informative References . . . . . . . . . . . . . . . . . . . . 37 A.5.3. Encrypted and Signed Message
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 38 A.5.4. Detached Signature
A.1. Sample v6 Ed25519 with ML-KEM-768+X25519 Data . . . . . . 38 A.6. Sample SLH-DSA-SHAKE-128f with ML-KEM-768+X25519 Data
A.1.1. Transferable Secret Key . . . . . . . . . . . . . . . 38 A.6.1. Transferable Secret Key
A.1.2. Transferable Public Key . . . . . . . . . . . . . . . 40 A.6.2. Transferable Public Key
A.1.3. Encrypted and Signed Message . . . . . . . . . . . . 42 A.6.3. Detached Signature
A.2. Sample v4 Ed25519 with ML-KEM-768+X25519 Data . . . . . . 44 A.7. Sample SLH-DSA-SHAKE-256s with ML-KEM-1024+X448 Data
A.2.1. Transferable Secret Key . . . . . . . . . . . . . . . 44 A.7.1. Transferable Secret Key
A.2.2. Transferable Public Key . . . . . . . . . . . . . . . 46 A.7.2. Transferable Public Key
A.2.3. Encrypted and Signed SEIPD v1 Message . . . . . . . . 48 A.7.3. Detached Signature
A.2.4. Encrypted and Signed SEIPD v2 Message . . . . . . . . 49 Acknowledgments
A.3. Sample ML-DSA-65+Ed25519 with ML-KEM-768+X25519 Data . . 50 Contributors
A.3.1. Transferable Secret Key . . . . . . . . . . . . . . . 51 Authors' Addresses
A.3.2. Transferable Public Key . . . . . . . . . . . . . . . 57
A.3.3. Encrypted and Signed Message . . . . . . . . . . . . 64
A.3.4. Detached Signature . . . . . . . . . . . . . . . . . 66
A.4. Sample ML-DSA-87+Ed448 with ML-KEM-1024+X448 Data . . . . 68
A.4.1. Transferable Secret Key . . . . . . . . . . . . . . . 68
A.4.2. Transferable Public Key . . . . . . . . . . . . . . . 77
A.4.3. Encrypted and Signed Message . . . . . . . . . . . . 85
A.4.4. Detached Signature . . . . . . . . . . . . . . . . . 89
A.5. Sample SLH-DSA-SHAKE-128s with ML-KEM-768+X25519 Data . . 91
A.5.1. Transferable Secret Key . . . . . . . . . . . . . . . 91
A.5.2. Transferable Public Key . . . . . . . . . . . . . . . 103
A.5.3. Encrypted and Signed Message . . . . . . . . . . . . 114
A.5.4. Detached Signature . . . . . . . . . . . . . . . . . 119
A.6. Sample SLH-DSA-SHAKE-128f with ML-KEM-768+X25519 Data . . 122
A.6.1. Transferable Secret Key . . . . . . . . . . . . . . . 122
A.6.2. Transferable Public Key . . . . . . . . . . . . . . . 146
A.6.3. Detached Signature . . . . . . . . . . . . . . . . . 169
A.7. Sample SLH-DSA-SHAKE-256s with ML-KEM-1024+X448 Data . . 177
A.7.1. Transferable Secret Key . . . . . . . . . . . . . . . 177
A.7.2. Transferable Public Key . . . . . . . . . . . . . . . 218
A.7.3. Detached Signature . . . . . . . . . . . . . . . . . 258
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 271
1. Introduction 1. Introduction
The OpenPGP protocol [RFC9580] supports various traditional public The OpenPGP protocol [RFC9580] supports various traditional public
key algorithms based on the factoring or discrete logarithm problem. key algorithms based on the factoring or discrete logarithm problem.
As the security of algorithms based on these mathematical problems is As the security of algorithms based on these mathematical problems is
endangered by the advent of quantum computers, there is a need to endangered by the advent of quantum computers, there is a need to
extend OpenPGP with algorithms that remain secure in the presence of extend OpenPGP with algorithms that remain secure in the presence of
a cryptographically relevant quantum computer (CRQC), i.e., a quantum a Cryptographically Relevant Quantum Computer (CRQC), i.e., a quantum
computer with sufficient capacity to break traditional public key computer with sufficient capacity to break traditional public key
cryptography. cryptography.
Such cryptographic algorithms are referred to as post-quantum Such cryptographic algorithms are referred to as "Post-Quantum
cryptography (PQC). The algorithms defined in this extension were Cryptography" (or "PQC"). The algorithms defined in this extension
chosen for standardization by the US National Institute of Standards were chosen for standardization by the US National Institute of
and Technology (NIST) in mid-2022 [NISTIR-8413] as the result of the Standards and Technology (NIST) in mid-2022 [NISTIR-8413] as the
NIST Post-Quantum Cryptography Standardization process initiated in result of the NIST Post-Quantum Cryptography Standardization process
2016 [NIST-PQC]. Namely, these are ML-KEM [FIPS-203] as a Key initiated in 2016 [NIST-PQC]. Namely, these are ML-KEM [FIPS-203] as
Encapsulation Mechanism (KEM), a KEM being a modern building block a Key Encapsulation Mechanism (KEM), a KEM being a modern building
for public key encryption, and ML-DSA [FIPS-204] as well as SLH-DSA block for public key encryption, and ML-DSA [FIPS-204] as well as
[FIPS-205] as signature schemes. SLH-DSA [FIPS-205] as signature schemes.
For the two ML-* schemes, this document follows the conservative For the ML-KEM and ML-DSA schemes, this document follows the
strategy to deploy post-quantum in combination with traditional conservative strategy to deploy post-quantum in combination with
schemes such that the security is retained even if all schemes but traditional schemes such that the security is retained even if all
one in the combination are broken. Such combinations are referred to schemes but one in the combination are broken. Such combinations are
as multi-algorithm or "post-quantum/traditional" (PQ/T) hybrid referred to as "multi-algorithm" or "post-quantum/traditional" (or
algorithms. In contrast, the stateless hash-based signature scheme "PQ/T") hybrid algorithms. In contrast, the stateless hash-based
SLH-DSA is considered to be sufficiently well understood with respect signature scheme SLH-DSA is considered to be sufficiently well
to its security assumptions in order to be used standalone. To this understood with respect to its security assumptions in order to be
end, this document specifies the following new set: SLH-DSA used standalone. To this end, this document specifies the following
standalone and the two ML-* as composite with ECC-based KEM and new set: SLH-DSA standalone and the two ML-* as composite with KEM
digital signature schemes. Here, the term "composite" indicates that based on ECC and digital signature schemes. Here, the term
any data structure or algorithm pertaining to the combination of the "composite" indicates that any data structure or algorithm pertaining
two components appears as a single data structure or algorithm from to the combination of the two components appears as a single data
the protocol perspective. structure or algorithm from the protocol perspective.
This document extends [RFC9580] by adding KEM and signature This document extends [RFC9580] by adding KEM and signature
algorithms specified in Section 4, Section 5, and Section 6 and algorithms specified in Sections 4, 5, and 6 and specifies the
specifies the conventions for interoperability between compliant conventions for interoperability between compliant OpenPGP
OpenPGP implementations. implementations.
1.1. Conventions used in this Document 1.1. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
In wire format descriptions, the operator "||" is used to indicate In wire format descriptions, the operator "||" is used to indicate
concatenation of groups of octets. concatenation of groups of octets.
skipping to change at page 6, line 41 skipping to change at line 235
therein. The abbreviation "PQ" is used for post-quantum schemes. To therein. The abbreviation "PQ" is used for post-quantum schemes. To
denote the combination of post-quantum and traditional schemes, the denote the combination of post-quantum and traditional schemes, the
abbreviation "PQ/T" is used. The short form "PQ(/T)" stands for PQ abbreviation "PQ/T" is used. The short form "PQ(/T)" stands for PQ
or PQ/T. or PQ/T.
1.2. Post-Quantum Cryptography 1.2. Post-Quantum Cryptography
This section describes the individual post-quantum cryptographic This section describes the individual post-quantum cryptographic
schemes. All schemes listed here are designed to provide security in schemes. All schemes listed here are designed to provide security in
the presence of a CRQC. However, the mathematical problems on which the presence of a CRQC. However, the mathematical problems on which
the two ML-* schemes and SLH-DSA are based, are fundamentally the two ML-* schemes and SLH-DSA are based are fundamentally
different, and accordingly the level of trust commonly placed in them different, and, accordingly, the level of trust commonly placed in
as well as their performance characteristics vary. them as well as their performance characteristics vary.
1.2.1. ML-KEM 1.2.1. ML-KEM
ML-KEM [FIPS-203] is based on the hardness of solving the Learning ML-KEM [FIPS-203] is based on the hardness of solving the Learning
with Errors problem in module lattices (MLWE). The scheme is with Errors problem in module lattices (MLWE). The scheme is
believed to provide security against cryptanalytic attacks based on believed to provide security against cryptanalytic attacks based on
classical as well as quantum algorithms. This specification defines classical as well as quantum algorithms. This specification defines
ML-KEM only in composite combination with ECDH encryption schemes in ML-KEM only in composite combination with Elliptic Curve Diffie-
order to provide a pre-quantum security fallback. Hellman (ECDH) encryption schemes in order to provide a pre-quantum
security fallback.
1.2.2. ML-DSA 1.2.2. ML-DSA
ML-DSA [FIPS-204] is a signature scheme that, like ML-KEM, is based ML-DSA [FIPS-204] is a signature scheme that, like ML-KEM, is based
on the hardness of solving the Learning With Errors problem and a on the hardness of solving the MLWE problem and a variant of the
variant of the Short Integer Solution problem in module lattices Short Integer Solution problem in module lattices (MLWE and
(MLWE and SelfTargetMSIS). Accordingly, this specification only SelfTargetMSIS). Accordingly, this specification only defines ML-DSA
defines ML-DSA in composite combination with EdDSA signature schemes. in composite combination with Edwards-Curve Digital Signature
Algorithm (EdDSA) signature schemes.
1.2.3. SLH-DSA 1.2.3. SLH-DSA
SLH-DSA [FIPS-205] is a stateless hash-based signature scheme. Its SLH-DSA [FIPS-205] is a stateless hash-based signature scheme. Its
security relies on the hardness of finding preimages for security relies on the hardness of finding preimages for
cryptographic hash functions. This feature is generally considered cryptographic hash functions. This feature is generally considered
to be a high security guarantee. Therefore, this specification to be a high security guarantee. Therefore, this specification
defines SLH-DSA as a standalone signature scheme. defines SLH-DSA as a standalone signature scheme.
In deployments the performance characteristics of SLH-DSA should be In deployments, the performance characteristics of SLH-DSA should be
taken into account. The performance characteristics of this scheme taken into account. The performance characteristics of this scheme
are discussed in Section 10.1. are discussed in Section 10.1.
1.3. Elliptic Curve Cryptography 1.3. Elliptic Curve Cryptography
ECDH encryption is defined here as a KEM via X25519 and X448 which ECDH encryption is defined here as a KEM via X25519 and X448, which
are defined in [RFC7748]. EdDSA as defined in [RFC8032] is used as are defined in [RFC7748]. EdDSA as defined in [RFC8032] is used as
the elliptic curve-based digital signature scheme. the elliptic curve-based digital signature scheme.
1.4. Standalone and Multi-Algorithm Schemes 1.4. Standalone and Multi-Algorithm Schemes
This section provides a categorization of the new algorithms and This section provides a categorization of the new algorithms and
their combinations. their combinations.
1.4.1. Standalone and Composite Multi-Algorithm Schemes 1.4.1. Standalone and Composite Multi-Algorithm Schemes
This specification introduces new cryptographic schemes, which can be This specification introduces new cryptographic schemes, which can be
categorized as follows: categorized as follows:
* PQ/T multi-algorithm public key encryption, namely a composite * PQ/T multi-algorithm public key encryption, namely a composite
combination of ML-KEM with ECDH, combination of ML-KEM with ECDH,
* PQ/T multi-algorithm digital signature, namely composite * PQ/T multi-algorithm digital signature, namely composite
combinations of ML-DSA with EdDSA, combinations of ML-DSA with EdDSA, and
* PQ digital signature, namely SLH-DSA as a standalone cryptographic * PQ digital signature, namely SLH-DSA as a standalone cryptographic
algorithm. algorithm.
For each of the composite schemes, this specification mandates that For each of the composite schemes, this specification mandates that
the consuming party successfully perform the cryptographic algorithms the consuming party successfully perform the cryptographic algorithms
for each of the component schemes used in a cryptographic message, for each of the component schemes used in a cryptographic message,
for the message to be deciphered and considered as valid. This means for the message to be deciphered and considered as valid. This means
that all component signatures must be verified successfully to that all component signatures must be verified successfully to
achieve a successful verification of the composite signature. In the achieve a successful verification of the composite signature. In the
skipping to change at page 9, line 19 skipping to change at line 345
+----+--------------------+-------------+-------------+ +----+--------------------+-------------+-------------+
| 31 | ML-DSA-87+Ed448 | SHOULD | Section 5.2 | | 31 | ML-DSA-87+Ed448 | SHOULD | Section 5.2 |
+----+--------------------+-------------+-------------+ +----+--------------------+-------------+-------------+
| 32 | SLH-DSA-SHAKE-128s | MAY | Section 6.1 | | 32 | SLH-DSA-SHAKE-128s | MAY | Section 6.1 |
+----+--------------------+-------------+-------------+ +----+--------------------+-------------+-------------+
| 33 | SLH-DSA-SHAKE-128f | MAY | Section 6.1 | | 33 | SLH-DSA-SHAKE-128f | MAY | Section 6.1 |
+----+--------------------+-------------+-------------+ +----+--------------------+-------------+-------------+
| 34 | SLH-DSA-SHAKE-256s | MAY | Section 6.1 | | 34 | SLH-DSA-SHAKE-256s | MAY | Section 6.1 |
+----+--------------------+-------------+-------------+ +----+--------------------+-------------+-------------+
Table 1: Signature algorithm specifications Table 1: Signature Algorithm Specifications
For encryption, the following composite KEM schemes are specified: For encryption, the following composite KEM schemes are specified:
+====+===================+=============+=============+ +====+===================+=============+=============+
| ID | Algorithm | Requirement | Definition | | ID | Algorithm | Requirement | Definition |
+====+===================+=============+=============+ +====+===================+=============+=============+
| 35 | ML-KEM-768+X25519 | MUST | Section 4.2 | | 35 | ML-KEM-768+X25519 | MUST | Section 4.2 |
+----+-------------------+-------------+-------------+ +----+-------------------+-------------+-------------+
| 36 | ML-KEM-1024+X448 | SHOULD | Section 4.2 | | 36 | ML-KEM-1024+X448 | SHOULD | Section 4.2 |
+----+-------------------+-------------+-------------+ +----+-------------------+-------------+-------------+
Table 2: KEM algorithm specifications Table 2: KEM Algorithm Specifications
A conformant implementation MUST implement ML-DSA-65+Ed25519 and ML- A conformant implementation MUST implement ML-DSA-65+Ed25519 and ML-
KEM-768+X25519. It SHOULD also implement ML-DSA-87+Ed448 and ML-KEM- KEM-768+X25519. It SHOULD also implement ML-DSA-87+Ed448 and ML-KEM-
1024+X448, but may omit them if targeting a highly constrained 1024+X448, but it may omit them if targeting a highly constrained
environment. An implementation MAY implement any of the SLH-DSA environment. An implementation MAY implement any of the SLH-DSA
algorithms. algorithms.
The specified algorithm IDs offer two security levels for each The specified algorithm IDs offer two security levels for each
scheme, for a tradeoff between security and performance. The SLH-DSA scheme, for a trade-off between security and performance. The SLH-
algorithms offer an additional performance tradeoff between signature DSA algorithms offer an additional performance trade-off between
generation time ("128f" is faster) and signature size ("128s" is signature generation time ("128f" is faster) and signature size
smaller) at the lower of the two SLH-DSA security levels. The larger ("128s" is smaller) at the lower of the two SLH-DSA security levels.
parameter sets of ML-DSA and ML-KEM (Algorithm IDs 31 and 36) are The larger parameter sets of ML-DSA and ML-KEM (Algorithm IDs 31 and
recommended to support interoperability, but they are not required 36) are recommended to support interoperability, but they are not
for compliance. Implementations targeting highly constrained required for compliance. Implementations targeting highly
environments may omit these larger variants. constrained environments may omit these larger variants.
For SLH-DSA-SHAKE-256, only the "small" variant is offered to contain For SLH-DSA-SHAKE-256, only the "small" variant is offered to contain
signature size. See also Section 10.1 for further considerations signature size. See also Section 10.1 for further considerations
about parameter choices. about parameter choices.
3. Algorithm Combinations 3. Algorithm Combinations
3.1. Composite KEMs 3.1. Composite KEMs
The ML-KEM + ECDH public key encryption involves both the ML-KEM and The ML-KEM + ECDH public key encryption involves both the ML-KEM and
an ECDH KEM in an a priori non-separable manner. This is achieved an ECDH KEM in an a priori inseparable manner. This is achieved via
via KEM combination, that is, both key encapsulations/decapsulations KEM combination, that is, both key encapsulations/decapsulations are
are performed in parallel, and the resulting key shares are fed into performed in parallel, and the resulting key shares are fed into a
a key combiner to produce a single shared secret for message key combiner to produce a single shared secret for message
encryption. encryption.
As explained in Section 1.4.2, the OpenPGP protocol inherently As explained in Section 1.4.2, the OpenPGP protocol inherently
supports parallel encryption to different keys. Note that the supports parallel encryption to different keys. Note that the
confidentiality of a message is not post-quantum secure when confidentiality of a message is not post-quantum secure when
encrypting to different keys unless all keys support PQ(/T) encrypting to different keys unless all keys support PQ(/T)
encryption schemes. encryption schemes.
3.2. Composite Signatures 3.2. Composite Signatures
skipping to change at page 11, line 6 skipping to change at line 429
3.4. ECC Requirements 3.4. ECC Requirements
Even though the zero point, also called the point at infinity, may Even though the zero point, also called the point at infinity, may
occur as a result of arithmetic operations on points of an elliptic occur as a result of arithmetic operations on points of an elliptic
curve, it MUST NOT appear in any ECC data structure defined in this curve, it MUST NOT appear in any ECC data structure defined in this
document. An implementation MAY signal an error if this condition is document. An implementation MAY signal an error if this condition is
encountered. encountered.
Furthermore, when performing the explicitly listed operations in Furthermore, when performing the explicitly listed operations in
Section 4.1.1.1 or Section 4.1.1.2 it is REQUIRED to follow the Sections 4.1.1.1 or 4.1.1.2, it is REQUIRED to follow the
specification and security advisory mandated from the respective specification and security advisory mandated from the respective
elliptic curve specification [RFC7748]. elliptic curve specification [RFC7748].
3.5. Key Version Binding 3.5. Key Version Binding
All PQ(/T) asymmetric algorithms are to be used only in v6 (and All PQ(/T) asymmetric algorithms are to be used only in v6 (and
newer) keys and certificates, with the single exception of ML-KEM- newer) keys and certificates, with the single exception of ML-KEM-
768+X25519 (algorithm ID 35), which is also allowed in v4 encryption- 768+X25519 (algorithm ID 35), which is also allowed in v4 encryption-
capable subkeys. capable subkeys.
skipping to change at page 11, line 46 skipping to change at line 469
+------------------------+-------------------+-------------------+ +------------------------+-------------------+-------------------+
| ECDH public key | 32 octets | 56 octets | | ECDH public key | 32 octets | 56 octets |
+------------------------+-------------------+-------------------+ +------------------------+-------------------+-------------------+
| ECDH secret key | 32 octets | 56 octets | | ECDH secret key | 32 octets | 56 octets |
+------------------------+-------------------+-------------------+ +------------------------+-------------------+-------------------+
| ECDH ephemeral | 32 octets | 56 octets | | ECDH ephemeral | 32 octets | 56 octets |
+------------------------+-------------------+-------------------+ +------------------------+-------------------+-------------------+
| ECDH key share | 32 octets | 56 octets | | ECDH key share | 32 octets | 56 octets |
+------------------------+-------------------+-------------------+ +------------------------+-------------------+-------------------+
Table 3: Montgomery curve parameters and artifact lengths Table 3: Montgomery Curve Parameters and Artifact Lengths
The various procedures to perform the operations of an ECDH KEM are The various procedures to perform the operations of an ECDH KEM are
defined in the following subsections. Specifically, each of these defined in the following subsections. Specifically, each of these
subsections defines the instances of the following operations: subsections defines the instances of the following operations:
(ecdhCipherText, ecdhKeyShare) <- ECDH-KEM.Encaps(ecdhPublicKey) (ecdhCipherText, ecdhKeyShare) <- ECDH-KEM.Encaps(ecdhPublicKey)
and and
(ecdhKeyShare) <- ECDH-KEM.Decaps(ecdhCipherText, ecdhSecretKey) (ecdhKeyShare) <- ECDH-KEM.Decaps(ecdhCipherText, ecdhSecretKey)
To instantiate ECDH-KEM, one must select a parameter set from To instantiate ECDH-KEM, one must select a parameter set from
Table 3. Table 3.
4.1.1.1. X25519-KEM 4.1.1.1. X25519-KEM
The encapsulation and decapsulation operations of X25519-KEM are The encapsulation and decapsulation operations of X25519-KEM are
described using the function X25519() and encodings defined in described using the function X25519() and encodings defined in
[RFC7748]. The ecdhSecretKey is denoted as r, the ecdhPublicKey as [RFC7748]. The ecdhSecretKey is denoted as r and the ecdhPublicKey
R, they are subject to the equation R = X25519(r, U(P)). Here, U(P) as R; they are subject to the equation R = X25519(r, U(P)). Here,
denotes the u-coordinate of the base point of Curve25519. U(P) denotes the u-coordinate of the base point of Curve25519.
The operation X25519-KEM.Encaps() is defined as follows: The operation X25519-KEM.Encaps() is defined as follows:
1. Generate an ephemeral key pair {v, V} via V = X25519(v,U(P)) 1. Generate an ephemeral key pair {v, V} via V = X25519(v,U(P))
where v is a randomly generated octet string with a length of 32 where v is a randomly generated octet string with a length of 32
octets octets
2. Compute the shared coordinate X = X25519(v, R) where R is the 2. Compute the shared coordinate X = X25519(v, R) where R is the
recipient's public key ecdhPublicKey recipient's public key ecdhPublicKey
skipping to change at page 12, line 43 skipping to change at line 516
1. Compute the shared coordinate X = X25519(r, V), where r is the 1. Compute the shared coordinate X = X25519(r, V), where r is the
ecdhSecretKey and V is the ecdhCipherText ecdhSecretKey and V is the ecdhCipherText
2. Set the output ecdhKeyShare to X 2. Set the output ecdhKeyShare to X
4.1.1.2. X448-KEM 4.1.1.2. X448-KEM
The encapsulation and decapsulation operations of X448-KEM are The encapsulation and decapsulation operations of X448-KEM are
described using the function X448() and encodings defined in described using the function X448() and encodings defined in
[RFC7748]. The ecdhSecretKey is denoted as r, the ecdhPublicKey as [RFC7748]. The ecdhSecretKey is denoted as r and the ecdhPublicKey
R, they are subject to the equation R = X448(r, U(P)). Here, U(P) as R; they are subject to the equation R = X448(r, U(P)). Here, U(P)
denotes the u-coordinate of the base point of Curve448. denotes the u-coordinate of the base point of Curve448.
The operation X448-KEM.Encaps() is defined as follows: The operation X448-KEM.Encaps() is defined as follows:
1. Generate an ephemeral key pair {v, V} via V = X448(v,U(P)) where 1. Generate an ephemeral key pair {v, V} via V = X448(v,U(P)) where
v is a randomly generated octet string with a length of 56 octets v is a randomly generated octet string with a length of 56 octets
2. Compute the shared coordinate X = X448(v, R) where R is the 2. Compute the shared coordinate X = X448(v, R) where R is the
recipient's public key ecdhPublicKey recipient's public key ecdhPublicKey
skipping to change at page 13, line 51 skipping to change at line 571
+-------------------------------+-------------+-------------+ +-------------------------------+-------------+-------------+
| Public (encapsulation) key | 1184 octets | 1568 octets | | Public (encapsulation) key | 1184 octets | 1568 octets |
+-------------------------------+-------------+-------------+ +-------------------------------+-------------+-------------+
| Secret (decapsulation) key | 64 octets | 64 octets | | Secret (decapsulation) key | 64 octets | 64 octets |
+-------------------------------+-------------+-------------+ +-------------------------------+-------------+-------------+
| Ciphertext | 1088 octets | 1568 octets | | Ciphertext | 1088 octets | 1568 octets |
+-------------------------------+-------------+-------------+ +-------------------------------+-------------+-------------+
| Key share (shared secret key) | 32 octets | 32 octets | | Key share (shared secret key) | 32 octets | 32 octets |
+-------------------------------+-------------+-------------+ +-------------------------------+-------------+-------------+
Table 4: ML-KEM parameters and artifact lengths Table 4: ML-KEM Parameters and Artifact Lengths
To instantiate ML-KEM, one must select a parameter set from the To instantiate ML-KEM, one must select a parameter set from the
column "ML-KEM" of Table 4. column "ML-KEM" of Table 4.
4.2. Composite Encryption Schemes with ML-KEM 4.2. Composite Encryption Schemes with ML-KEM
Table 2 specifies the following ML-KEM + ECDH composite public key Table 2 specifies the following ML-KEM + ECDH composite public key
encryption schemes: encryption schemes:
+========================+=============+============+ +========================+=============+============+
| Algorithm ID reference | ML-KEM | ECDH-KEM | | Algorithm ID reference | ML-KEM | ECDH-KEM |
+========================+=============+============+ +========================+=============+============+
| 35 | ML-KEM-768 | X25519-KEM | | 35 | ML-KEM-768 | X25519-KEM |
+------------------------+-------------+------------+ +------------------------+-------------+------------+
| 36 | ML-KEM-1024 | X448-KEM | | 36 | ML-KEM-1024 | X448-KEM |
+------------------------+-------------+------------+ +------------------------+-------------+------------+
Table 5: ML-KEM + ECDH composite schemes Table 5: ML-KEM + ECDH Composite Schemes
The ML-KEM + ECDH composite public key encryption schemes are built The ML-KEM + ECDH composite public key encryption schemes are built
according to the following principal design: according to the following principal design:
* The ML-KEM encapsulation algorithm is invoked to create an ML-KEM * The ML-KEM encapsulation algorithm is invoked to create an ML-KEM
ciphertext together with an ML-KEM symmetric key share. ciphertext together with an ML-KEM symmetric key share.
* The encapsulation algorithm of an ECDH KEM, namely X25519-KEM or * The encapsulation algorithm of an ECDH KEM, namely X25519-KEM or
X448-KEM, is invoked to create an ECDH ciphertext together with an X448-KEM, is invoked to create an ECDH ciphertext together with an
ECDH symmetric key share. ECDH symmetric key share.
* A Key Encryption Key (KEK) is computed as the output of a key * A Key Encryption Key (KEK) is computed as the output of a key
combiner that receives as input both of the above created combiner that receives as input both of the above created
symmetric key shares, the ECDH ciphertext, the ECDH public key, symmetric key shares, the ECDH ciphertext, the ECDH public key,
and the protocol binding information. and the protocol binding information.
* The session key for content encryption, generated as specified in * The session key for content encryption, generated as specified in
[RFC9580], is then wrapped as described in [RFC3394] using AES-256 [RFC9580], is then wrapped as described in [RFC3394] using AES-256
as algorithm and the KEK as key. as the algorithm and the KEK as the key.
* The PKESK packet's algorithm-specific parts are made up of the ML- * The PKESK packet's algorithm-specific parts are made up of the ML-
KEM ciphertext, the ECDH ciphertext, and the wrapped session key. KEM ciphertext, the ECDH ciphertext, and the wrapped session key.
4.2.1. Key Combiner 4.2.1. Key Combiner
For the composite KEM schemes defined in Table 2 the following For the composite KEM schemes defined in Table 2, the following
procedure MUST be used to compute the KEK that wraps a session key. procedure MUST be used to compute the KEK that wraps a session key.
The construction is a key derivation function compliant to the QSF/ The construction is a key derivation function compliant with the QSF/
X-Wing construction in [BCD_24], the generalization of which is X-Wing construction in [BCD_24], the generalization of which is
analyzed in [CHHKM]. It is given by the following algorithm, which analyzed in [CHHKM]. It is given by the following algorithm, which
computes the key encryption key KEK that is used to wrap (that is, computes the KEK that is used to wrap (that is, encrypt) the session
encrypt) the session key. key.
// multiKeyCombine( // multiKeyCombine(
// mlkemKeyShare, ecdhKeyShare, // mlkemKeyShare, ecdhKeyShare,
// ecdhCipherText, ecdhPublicKey, // ecdhCipherText, ecdhPublicKey,
// algId // algId
// ) // )
// //
// Input: // Input:
// mlkemKeyShare - the ML-KEM key share encoded as an octet string // mlkemKeyShare - the ML-KEM key share encoded as an octet string
// ecdhKeyShare - the ECDH key share encoded as an octet string // ecdhKeyShare - the ECDH key share encoded as an octet string
skipping to change at page 15, line 33 skipping to change at line 650
ecdhCipherText || ecdhPublicKey || ecdhCipherText || ecdhPublicKey ||
algId || domSep || len(domSep) algId || domSep || len(domSep)
) )
return KEK return KEK
The value domSep is a constant set to the UTF-8 encoding of the The value domSep is a constant set to the UTF-8 encoding of the
string "OpenPGPCompositeKDFv1", that is: string "OpenPGPCompositeKDFv1", that is:
domSep = 4F 70 65 6E 50 47 50 43 6F 6D 70 6F 73 69 74 65 4B 44 46 76 31 domSep = 4F 70 65 6E 50 47 50 43 6F 6D 70 6F 73 69 74 65 4B 44 46 76 31
Here len(domSep) is the single octet with the value equal to the Here, len(domSep) is the single octet with the value equal to the
octet-length of domSep, that is, decimal 21. octet-length of domSep, that is, decimal 21.
4.2.2. Key Generation Procedure 4.2.2. Key Generation Procedure
The implementation MUST generate the ML-KEM and the ECDH component The implementation MUST generate the ML-KEM and the ECDH component
keys independently. ML-KEM key generation follows the specification keys independently. ML-KEM key generation follows the specification
in [FIPS-203], and the artifacts are encoded as fixed-length octet in [FIPS-203], and the artifacts are encoded as fixed-length octet
strings whose sizes are listed in Section 4.1.2. ECDH key generation strings whose sizes are listed in Section 4.1.2. ECDH key generation
follows the specification in [RFC7748], and the artifacts are encoded follows the specification in [RFC7748], and the artifacts are encoded
as fixed-length octet strings whose sizes are listed in Table 3. as fixed-length octet strings whose sizes are listed in Table 3.
skipping to change at page 16, line 7 skipping to change at line 672
4.2.3. Encryption Procedure 4.2.3. Encryption Procedure
The procedure to perform public key encryption with an ML-KEM + ECDH The procedure to perform public key encryption with an ML-KEM + ECDH
composite scheme is as follows: composite scheme is as follows:
1. Take the recipient's authenticated public key packet pkComposite 1. Take the recipient's authenticated public key packet pkComposite
and sessionKey as input and sessionKey as input
2. Parse the algorithm ID from pkComposite and set it as algId 2. Parse the algorithm ID from pkComposite and set it as algId
3. Extract the ecdhPublicKey and mlkemPublicKey component from the 3. Extract the ecdhPublicKey and mlkemPublicKey components from the
algorithm specific data encoded in pkComposite with the format algorithm-specific data encoded in pkComposite with the format
specified in Section 4.3.2. specified in Section 4.3.2
4. Instantiate the ECDH-KEM and the ML-KEM depending on the 4. Instantiate the ECDH-KEM and the ML-KEM depending on the
algorithm ID according to Table 5 algorithm ID according to Table 5
5. Compute (ecdhCipherText, ecdhKeyShare) = ECDH- 5. Compute (ecdhCipherText, ecdhKeyShare) = ECDH-
KEM.Encaps(ecdhPublicKey) KEM.Encaps(ecdhPublicKey)
6. Compute (mlkemCipherText, mlkemKeyShare) = ML- 6. Compute (mlkemCipherText, mlkemKeyShare) = ML-
KEM.Encaps(mlkemPublicKey) KEM.Encaps(mlkemPublicKey)
7. Compute KEK = multiKeyCombine(mlkemKeyShare, ecdhKeyShare, 7. Compute KEK = multiKeyCombine(mlkemKeyShare, ecdhKeyShare,
ecdhCipherText, ecdhPublicKey, algId) as defined in Section 4.2.1 ecdhCipherText, ecdhPublicKey, algId) as defined in Section 4.2.1
8. Compute C = AESKeyWrap(KEK, sessionKey) with AES-256 as per 8. Compute C = AESKeyWrap(KEK, sessionKey) with AES-256 as per
[RFC3394] that includes a 64 bit integrity check [RFC3394] that includes a 64-bit integrity check
9. Output the algorithm specific part of the PKESK as 9. Output the algorithm-specific part of the PKESK as
ecdhCipherText || mlkemCipherText || len(C, symAlgId) (|| ecdhCipherText || mlkemCipherText || len(C, symAlgId) (||
symAlgId) || C, where both symAlgId and len(C, symAlgId) are symAlgId) || C, where both symAlgId and len(C, symAlgId) are
single octet fields, symAlgId denotes the symmetric algorithm ID single-octet fields, symAlgId denotes the symmetric algorithm ID
used and is present only for a v3 PKESK, and len(C, symAlgId) used and is present only for a v3 PKESK, and len(C, symAlgId)
denotes the combined octet length of the fields specified as the denotes the combined octet length of the fields specified as the
arguments. arguments.
4.2.4. Decryption Procedure 4.2.4. Decryption Procedure
The procedure to perform public key decryption with an ML-KEM + ECDH The procedure to perform public key decryption with an ML-KEM + ECDH
composite scheme is as follows: composite scheme is as follows:
1. Take the matching PKESK and own secret key packet as input 1. Take the matching PKESK and own secret key packet as input
2. From the PKESK extract the algorithm ID as algId and the wrapped 2. From the PKESK, extract the algorithm ID as algId and the
session key as encryptedKey wrapped session key as encryptedKey
3. Check that the own and the extracted algorithm ID match 3. Check that the own and the extracted algorithm ID match
4. Parse the ecdhSecretKey and mlkemSecretKey from the algorithm 4. Parse the ecdhSecretKey and mlkemSecretKey from the algorithm-
specific data of the own secret key encoded in the format specific data of the own secret key encoded in the format
specified in Section 4.3.2 specified in Section 4.3.2
5. Instantiate the ECDH-KEM and the ML-KEM depending on the 5. Instantiate the ECDH-KEM and the ML-KEM depending on the
algorithm ID according to Table 5 algorithm ID according to Table 5
6. Parse ecdhCipherText, mlkemCipherText, and C from encryptedKey 6. Parse ecdhCipherText, mlkemCipherText, and C from encryptedKey
encoded as ecdhCipherText || mlkemCipherText || len(C, symAlgId) encoded as ecdhCipherText || mlkemCipherText || len(C, symAlgId)
(|| symAlgId) || C as specified in Section 4.3.1, where symAlgId (|| symAlgId) || C as specified in Section 4.3.1, where symAlgId
is present only in the case of a v3 PKESK. is present only in the case of a v3 PKESK
7. Compute (ecdhKeyShare) = ECDH-KEM.Decaps(ecdhCipherText, 7. Compute (ecdhKeyShare) = ECDH-KEM.Decaps(ecdhCipherText,
ecdhSecretKey) ecdhSecretKey)
8. Compute (mlkemKeyShare) = ML-KEM.Decaps(mlkemCipherText, 8. Compute (mlkemKeyShare) = ML-KEM.Decaps(mlkemCipherText,
mlkemSecretKey) mlkemSecretKey)
9. Compute KEK = multiKeyCombine(mlkemKeyShare, ecdhKeyShare, 9. Compute KEK = multiKeyCombine(mlkemKeyShare, ecdhKeyShare,
ecdhCipherText, ecdhPublicKey, algId) as defined in ecdhCipherText, ecdhPublicKey, algId) as defined in
Section 4.2.1 Section 4.2.1
10. Compute sessionKey = AESKeyUnwrap(KEK, C) with AES-256 as per 10. Compute sessionKey = AESKeyUnwrap(KEK, C) with AES-256 as per
[RFC3394], aborting if the 64 bit integrity check fails [RFC3394], aborting if the 64-bit integrity check fails
11. Output sessionKey 11. Output sessionKey
4.3. Packet Specifications 4.3. Packet Specifications
4.3.1. Public Key Encrypted Session Key Packets (Packet Type ID 1) 4.3.1. Public Key Encrypted Session Key Packets (Packet Type ID 1)
The algorithm-specific fields consist of the output of the encryption The algorithm-specific fields consist of the output of the encryption
procedure described in Section 4.2.3: procedure described in Section 4.2.3:
* A fixed-length octet string representing an ECDH ephemeral public * A fixed-length octet string representing an ECDH ephemeral public
key in the format associated with the curve as specified in key in the format associated with the curve as specified in
Section 4.1.1. Section 4.1.1.
* A fixed-length octet string of the ML-KEM ciphertext, whose length * A fixed-length octet string of the ML-KEM ciphertext whose length
depends on the algorithm ID as specified in Table 4. depends on the algorithm ID as specified in Table 4.
* A one-octet size of the following fields. * A one-octet size of the following fields.
* Only in the case of a v3 PKESK packet: a one-octet symmetric * (Only in the case of a v3 PKESK packet) a one-octet symmetric
algorithm identifier. algorithm identifier.
* The wrapped session key represented as an octet string. * The wrapped session key represented as an octet string.
Note that like in the case of the algorithms X25519 and X448 Note that like in the case of the algorithms X25519 and X448
specified in [RFC9580], for the ML-KEM composite schemes, in the case specified in [RFC9580], for the ML-KEM composite schemes, in the case
of a v3 PKESK packet, the symmetric algorithm identifier is not of a v3 PKESK packet, the symmetric algorithm identifier is not
encrypted. Instead, it is placed in plaintext after the encrypted. Instead, it is prepended to the wrapped session key in
mlkemCipherText and before the length octet preceding the wrapped plaintext and its length is included in the preceding length field.
session key. In the case of v3 PKESK packets for ML-KEM composite In the case of v3 PKESK packets for ML-KEM composite schemes, the
schemes, the symmetric algorithm used MUST be AES-128, AES-192 or symmetric algorithm used MUST be AES-128, AES-192 or AES-256
AES-256 (algorithm ID 7, 8 or 9). (algorithm IDs 7, 8, or 9).
In the case of a v3 PKESK, a receiving implementation MUST check if In the case of a v3 PKESK, a receiving implementation MUST check if
the length of the unwrapped symmetric key matches the symmetric the length of the unwrapped symmetric key matches the symmetric
algorithm identifier, and abort if this is not the case. algorithm ID and abort if this is not the case.
Implementations MUST NOT use the obsolete Symmetrically Encrypted Implementations MUST NOT use the obsolete Symmetrically Encrypted
Data packet (Packet Type ID 9) to encrypt data protected with the Data packet (Packet Type ID 9) to encrypt data protected with the
algorithms described in this document. algorithms described in this document.
4.3.2. Key Material Packets 4.3.2. Key Material Packets
The composite ML-KEM-768 + X25519 (algorithm ID 35) MUST be used only The composite ML-KEM-768 + X25519 (algorithm ID 35) MUST be used only
with v4 or v6 keys, as defined in [RFC9580], or newer versions with v4 or v6 keys, as defined in [RFC9580], or newer versions
defined by updates of that document. defined by updates of that document.
skipping to change at page 18, line 39 skipping to change at line 793
with v6 keys, as defined in [RFC9580], or newer versions defined by with v6 keys, as defined in [RFC9580], or newer versions defined by
updates of that document. updates of that document.
4.3.2.1. Public Key Packets (Packet Type IDs 6 and 14) 4.3.2.1. Public Key Packets (Packet Type IDs 6 and 14)
The algorithm-specific public key is this series of values: The algorithm-specific public key is this series of values:
* A fixed-length octet string representing an ECC public key, in the * A fixed-length octet string representing an ECC public key, in the
point format associated with the curve specified in Section 4.1.1. point format associated with the curve specified in Section 4.1.1.
* A fixed-length octet string containing the ML-KEM public key, * A fixed-length octet string containing the ML-KEM public key whose
whose length depends on the algorithm ID as specified in Table 4. length depends on the algorithm ID as specified in Table 4.
4.3.2.2. Secret Key Packets (Packet Type IDs 5 and 7) 4.3.2.2. Secret Key Packets (Packet Type IDs 5 and 7)
The algorithm-specific secret key is these two values: The algorithm-specific secret key is comprised of these two values:
* A fixed-length octet string of the encoded ECDH secret key, whose * A fixed-length octet string of the encoded ECDH secret key whose
encoding and length depend on the algorithm ID as specified in encoding and length depend on the algorithm ID as specified in
Section 4.1.1. Section 4.1.1.
* A fixed-length octet string containing the ML-KEM secret key in * A fixed-length octet string containing the ML-KEM secret key in
seed format, whose length is 64 octets (compare Table 4). The seed format whose length is 64 octets (compare Table 4). The seed
seed format is defined in accordance with Section 3.3 of format is defined in accordance with Section 3.3 of [FIPS-203].
Namely, the secret key is given by the concatenation of the values
[FIPS-203]. Namely, the secret key is given by the concatenation of d and z, generated in steps 1 and 2 of ML-KEM.KeyGen
of the values of d and z, generated in steps 1 and 2 of ML- [FIPS-203], each of a length of 32 octets. Upon parsing the
KEM.KeyGen [FIPS-203], each of a length of 32 octets. Upon secret key format, or before using the secret key, for the
parsing the secret key format, or before using the secret key, for expansion of the key, the function ML-KEM.KeyGen_internal
the expansion of the key, the function ML-KEM.KeyGen_internal
[FIPS-203] has to be invoked with the parsed values of d and z as [FIPS-203] has to be invoked with the parsed values of d and z as
input. input.
5. Composite Signature Schemes 5. Composite Signature Schemes
5.1. Building Blocks 5.1. Building Blocks
5.1.1. EdDSA-Based Signatures 5.1.1. EdDSA-Based Signatures
Throughout this specification EdDSA refers to the PureEdDSA variant Throughout this specification, "EdDSA" refers to the PureEdDSA
defined in [RFC8032]. The context is always empty. variant defined in [RFC8032]. The context is always empty.
To sign and verify with EdDSA the following operations are defined: To sign and verify with EdDSA, the following operations are defined:
(eddsaSignature) <- EdDSA.Sign(eddsaSecretKey, dataDigest) (eddsaSignature) <- EdDSA.Sign(eddsaSecretKey, dataDigest)
and and
(verified) <- EdDSA.Verify(eddsaPublicKey, dataDigest, eddsaSignature) (verified) <- EdDSA.Verify(eddsaPublicKey, dataDigest, eddsaSignature)
The public and secret key, as well as the signature MUST be encoded The public and secret key, as well as the signature, MUST be encoded
according to [RFC8032] as fixed-length octet strings. The following according to [RFC8032] as fixed-length octet strings. The following
table describes the EdDSA parameters and artifact lengths: table describes the EdDSA parameters and artifact lengths:
+========================+===========+============+ +========================+===========+============+
| | Ed25519 | Ed448 | | | Ed25519 | Ed448 |
+========================+===========+============+ +========================+===========+============+
| Algorithm ID reference | 30 | 31 | | Algorithm ID reference | 30 | 31 |
+------------------------+-----------+------------+ +------------------------+-----------+------------+
| Public key | 32 octets | 57 octets | | Public key | 32 octets | 57 octets |
+------------------------+-----------+------------+ +------------------------+-----------+------------+
| Secret key | 32 octets | 57 octets | | Secret key | 32 octets | 57 octets |
+------------------------+-----------+------------+ +------------------------+-----------+------------+
| Signature | 64 octets | 114 octets | | Signature | 64 octets | 114 octets |
+------------------------+-----------+------------+ +------------------------+-----------+------------+
Table 6: EdDSA parameters and artifact lengths Table 6: EdDSA Parameters and Artifact Lengths
5.1.2. ML-DSA Signatures 5.1.2. ML-DSA Signatures
Throughout this specification ML-DSA refers to the default pure and Throughout this specification, "ML-DSA" refers to the default pure
hedged version of ML-DSA defined in [FIPS-204]. and hedged version of ML-DSA defined in [FIPS-204].
ML-DSA signature generation is performed using the default hedged ML-DSA signature generation is performed using the default hedged
version of the ML-DSA.Sign algorithm, as specified in [FIPS-204], version of the ML-DSA.Sign algorithm, as specified in [FIPS-204],
with an empty context string ctx. That is, to sign with ML-DSA the with an empty context string ctx. That is, to sign with ML-DSA, the
following operation is defined: following operation is defined:
(mldsaSignature) <- ML-DSA.Sign(mldsaSecretKey, dataDigest) (mldsaSignature) <- ML-DSA.Sign(mldsaSecretKey, dataDigest)
ML-DSA signature verification is performed using the ML-DSA.Verify ML-DSA signature verification is performed using the ML-DSA.Verify
algorithm, as specified in [FIPS-204], with an empty context string algorithm, as specified in [FIPS-204], with an empty context string
ctx. That is, to verify with ML-DSA the following operation is ctx. That is, to verify with ML-DSA, the following operation is
defined: defined:
(verified) <- ML-DSA.Verify(mldsaPublicKey, dataDigest, mldsaSignature) (verified) <- ML-DSA.Verify(mldsaPublicKey, dataDigest, mldsaSignature)
ML-DSA has the parametrization with the corresponding artifact ML-DSA has the parametrization with the corresponding artifact
lengths in octets as given in Table 7. All artifacts are encoded as lengths in octets as given in Table 7. All artifacts are encoded as
defined in [FIPS-204]. defined in [FIPS-204].
+========================+=============+=============+ +========================+=============+=============+
| | ML-DSA-65 | ML-DSA-87 | | | ML-DSA-65 | ML-DSA-87 |
+========================+=============+=============+ +========================+=============+=============+
| Algorithm ID reference | 30 | 31 | | Algorithm ID reference | 30 | 31 |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| Public key | 1952 octets | 2592 octets | | Public key | 1952 octets | 2592 octets |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| Secret (Private) key | 32 octets | 32 octets | | Secret (Private) key | 32 octets | 32 octets |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
| Signature | 3309 octets | 4627 octets | | Signature | 3309 octets | 4627 octets |
+------------------------+-------------+-------------+ +------------------------+-------------+-------------+
Table 7: ML-DSA parameters and artifact lengths Table 7: ML-DSA Parameters and Artifact Lengths
5.2. Composite Signature Schemes with ML-DSA 5.2. Composite Signature Schemes with ML-DSA
5.2.1. Key Generation Procedure 5.2.1. Key Generation Procedure
The implementation MUST generate the ML-DSA and the EdDSA component The implementation MUST generate the ML-DSA and the EdDSA component
keys independently. ML-DSA key generation follows the specification keys independently. ML-DSA key generation follows the specification
in [FIPS-204], and the artifacts are encoded as fixed-length octet in [FIPS-204], and the artifacts are encoded as fixed-length octet
strings whose sizes are listed in Section 5.1.2. EdDSA key strings whose sizes are listed in Section 5.1.2. EdDSA key
generation follows the specification in [RFC8032], and the artifacts generation follows the specification in [RFC8032], and the artifacts
are encoded as fixed-length octet strings whose sizes are listed in are encoded as fixed-length octet strings whose sizes are listed in
Section 5.1.1. Section 5.1.1.
5.2.2. Signature Generation 5.2.2. Signature Generation
To sign a message M with ML-DSA + EdDSA the following sequence of To sign a message M with ML-DSA + EdDSA, the following sequence of
operations has to be performed: operations has to be performed:
1. Generate dataDigest according to Section 5.2.4 of [RFC9580] 1. Generate dataDigest according to Section 5.2.4 of [RFC9580]
2. Create the EdDSA signature over dataDigest with EdDSA.Sign() from 2. Create the EdDSA signature over dataDigest with EdDSA.Sign() from
Section 5.1.1 Section 5.1.1
3. Create the ML-DSA signature over dataDigest with ML-DSA.Sign() 3. Create the ML-DSA signature over dataDigest with ML-DSA.Sign()
from Section 5.1.2 from Section 5.1.2
4. Encode the EdDSA and ML-DSA signatures according to the packet 4. Encode the EdDSA and ML-DSA signatures according to the packet
structure given in Section 5.3.1 structure given in Section 5.3.1
5.2.3. Signature Verification 5.2.3. Signature Verification
To verify an ML-DSA + EdDSA signature the following sequence of To verify an ML-DSA + EdDSA signature, the following sequence of
operations has to be performed: operations has to be performed:
1. Verify the EdDSA signature with EdDSA.Verify() from Section 5.1.1 1. Verify the EdDSA signature with EdDSA.Verify() from Section 5.1.1
2. Verify the ML-DSA signature with ML-DSA.Verify() from 2. Verify the ML-DSA signature with ML-DSA.Verify() from
Section 5.1.2 Section 5.1.2
As specified in Section 5 an implementation MUST validate both As specified in Section 5, an implementation MUST validate both
signatures, that is, EdDSA and ML-DSA, successfully to state that a signatures, that is, EdDSA and ML-DSA, successfully to state that a
composite ML-DSA + EdDSA signature is valid. composite ML-DSA + EdDSA signature is valid.
5.3. Packet Specifications 5.3. Packet Specifications
5.3.1. Signature Packet (Packet Type ID 2) 5.3.1. Signature Packet (Packet Type ID 2)
The composite ML-DSA + EdDSA schemes MUST be used only with v6 The composite ML-DSA + EdDSA schemes MUST be used only with v6
signatures, as defined in [RFC9580], or newer versions defined by signatures, as defined in [RFC9580], or newer versions defined by
updates of that document. updates of that document.
The algorithm-specific v6 signature parameters for ML-DSA + EdDSA The algorithm-specific v6 signature parameters for ML-DSA + EdDSA
signatures consist of: signatures consist of:
* A fixed-length octet string representing the EdDSA signature, * A fixed-length octet string representing the EdDSA signature whose
whose length depends on the algorithm ID as specified in Table 6. length depends on the algorithm ID as specified in Table 6.
* A fixed-length octet string of the ML-DSA signature value, whose * A fixed-length octet string of the ML-DSA signature value whose
length depends on the algorithm ID as specified in Table 7. length depends on the algorithm ID as specified in Table 7.
A composite ML-DSA + EdDSA signature MUST use a hash algorithm with a A composite ML-DSA + EdDSA signature MUST use a hash algorithm with a
digest size of at least 256 bits for the computation of the message digest size of at least 256 bits for the computation of the message
digest. A verifying implementation MUST reject any composite ML-DSA digest. A verifying implementation MUST reject any composite ML-DSA
+ EdDSA signature that uses a hash algorithm with a smaller digest + EdDSA signature that uses a hash algorithm with a smaller digest
size. size.
5.3.2. Key Material Packets 5.3.2. Key Material Packets
The composite ML-DSA + EdDSA schemes MUST be used only with v6 keys, The composite ML-DSA + EdDSA schemes MUST be used only with v6 keys,
as defined in [RFC9580], or newer versions defined by updates of that as defined in [RFC9580], or newer versions defined by updates of that
document. document.
5.3.2.1. Public Key Packets (Packet Type IDs 6 and 14) 5.3.2.1. Public Key Packets (Packet Type IDs 6 and 14)
The algorithm-specific public key for ML-DSA + EdDSA keys is this The algorithm-specific public key for ML-DSA + EdDSA keys is this
series of values: series of values:
* A fixed-length octet string representing the EdDSA public key, * A fixed-length octet string representing the EdDSA public key
whose length depends on the algorithm ID as specified in Table 6. whose length depends on the algorithm ID as specified in Table 6.
* A fixed-length octet string containing the ML-DSA public key, * A fixed-length octet string containing the ML-DSA public key whose
whose length depends on the algorithm ID as specified in Table 7. length depends on the algorithm ID as specified in Table 7.
5.3.2.2. Secret Key Packets (Packet Type IDs 5 and 7) 5.3.2.2. Secret Key Packets (Packet Type IDs 5 and 7)
The algorithm-specific secret key for ML-DSA + EdDSA keys is this The algorithm-specific secret key for ML-DSA + EdDSA keys is this
series of values: series of values:
* A fixed-length octet string representing the EdDSA secret key, * A fixed-length octet string representing the EdDSA secret key
whose length depends on the algorithm ID as specified in Table 6. whose length depends on the algorithm ID as specified in Table 6.
* A fixed-length octet string containing the ML-DSA secret key in * A fixed-length octet string containing the ML-DSA secret key in
seed format, whose length is 32 octets (compare Table 7). The seed format whose length is 32 octets (compare Table 7). The seed
seed format is defined in accordance with Section 3.6.3 of format is defined in accordance with Section 3.6.3 of [FIPS-204].
[FIPS-204]. Namely, the secret key is given by the value xi Namely, the secret key is given by the value xi generated in step
generated in step 1 of ML-DSA.KeyGen [FIPS-204]. Upon parsing the 1 of ML-DSA.KeyGen [FIPS-204]. Upon parsing the secret key
secret key format, or before using the secret key, for the format, or before using the secret key, for the expansion of the
expansion of the key, the function ML-DSA.KeyGen_internal key, the function ML-DSA.KeyGen_internal [FIPS-204] has to be
[FIPS-204] has to be invoked with the parsed value of xi as input. invoked with the parsed value of xi as input.
6. SLH-DSA 6. SLH-DSA
Throughout this specification SLH-DSA refers to the default pure and Throughout this specification, "SLH-DSA" refers to the default pure
hedged version of SLH-DSA defined in [FIPS-205]. and hedged version of SLH-DSA defined in [FIPS-205].
6.1. The SLH-DSA Algorithms 6.1. The SLH-DSA Algorithms
The following table lists the group of algorithm code points for the The following table lists the group of algorithm code points for the
SLH-DSA signature scheme and the corresponding artifact lengths. SLH-DSA signature scheme and the corresponding artifact lengths.
This group of algorithms is henceforth referred to as "SLH-DSA code This group of algorithms is henceforth referred to as "SLH-DSA code
points". points".
+=========+==================+==================+==================+ +=========+==================+==================+==================+
| |SLH-DSA-SHAKE-128s|SLH-DSA-SHAKE-128f|SLH-DSA-SHAKE-256s| | |SLH-DSA-SHAKE-128s|SLH-DSA-SHAKE-128f|SLH-DSA-SHAKE-256s|
skipping to change at page 23, line 21 skipping to change at line 1014
+---------+------------------+------------------+------------------+ +---------+------------------+------------------+------------------+
|Public |32 octets |32 octets |64 octets | |Public |32 octets |32 octets |64 octets |
|key (PK) | | | | |key (PK) | | | |
+---------+------------------+------------------+------------------+ +---------+------------------+------------------+------------------+
|Secret |64 octets |64 octets |128 octets | |Secret |64 octets |64 octets |128 octets |
|key (SK) | | | | |key (SK) | | | |
+---------+------------------+------------------+------------------+ +---------+------------------+------------------+------------------+
|Signature|7856 octets |17088 octets |29792 octets | |Signature|7856 octets |17088 octets |29792 octets |
+---------+------------------+------------------+------------------+ +---------+------------------+------------------+------------------+
Table 8: SLH-DSA code points and the corresponding artifact lengths. Table 8: SLH-DSA Code Points and the Corresponding Artifact Lengths
6.1.1. Key Generation 6.1.1. Key Generation
SLH-DSA key generation is performed via the algorithm slh_keygen as SLH-DSA key generation is performed via the algorithm slh_keygen as
specified in [FIPS-205], and the artifacts are encoded as fixed- specified in [FIPS-205], and the artifacts are encoded as fixed-
length octet strings whose sizes are listed in Section 6.1. length octet strings whose sizes are listed in Section 6.1.
6.1.2. Signature Generation 6.1.2. Signature Generation
SLH-DSA signature generation is performed using the default hedged SLH-DSA signature generation is performed using the default hedged
skipping to change at page 24, line 5 skipping to change at line 1044
6.2. Packet Specifications 6.2. Packet Specifications
6.2.1. Signature Packet (Packet Type ID 2) 6.2.1. Signature Packet (Packet Type ID 2)
The SLH-DSA algorithms MUST be used only with v6 signatures, as The SLH-DSA algorithms MUST be used only with v6 signatures, as
defined in Section 5.2.3 of [RFC9580]. defined in Section 5.2.3 of [RFC9580].
The algorithm-specific part of a signature packet for an SLH-DSA code The algorithm-specific part of a signature packet for an SLH-DSA code
point consists of: point consists of:
* A fixed-length octet string of the SLH-DSA signature value, whose * A fixed-length octet string of the SLH-DSA signature value whose
length depends on the algorithm ID in the format specified in length depends on the algorithm ID in the format specified in
Table 8. Table 8.
An SLH-DSA signature MUST use a hash algorithm with a digest size of An SLH-DSA signature MUST use a hash algorithm with a digest size of
at least 256 bits for the computation of the message digest. A at least 256 bits for the computation of the message digest. A
verifying implementation MUST reject any SLH-DSA signature that uses verifying implementation MUST reject any SLH-DSA signature that uses
a hash algorithm with a smaller digest size. a hash algorithm with a smaller digest size.
6.2.2. Key Material Packets 6.2.2. Key Material Packets
The SLH-DSA code points MUST be used only with v6 keys, as defined in The SLH-DSA code points MUST be used only with v6 keys, as defined in
[RFC9580], or newer versions defined by updates of that document. [RFC9580], or newer versions defined by updates of that document.
6.2.2.1. Public Key Packets (Packet Type IDs 6 and 14) 6.2.2.1. Public Key Packets (Packet Type IDs 6 and 14)
The algorithm-specific part of the public key consists of: The algorithm-specific part of the public key consists of:
* A fixed-length octet string containing the SLH-DSA public key, * A fixed-length octet string containing the SLH-DSA public key
whose length depends on the algorithm ID as specified in Table 8. whose length depends on the algorithm ID as specified in Table 8.
6.2.2.2. Secret Key Packets (Packet Type IDs 5 and 7) 6.2.2.2. Secret Key Packets (Packet Type IDs 5 and 7)
The algorithm-specific part of the secret key consists of: The algorithm-specific part of the secret key consists of:
* A fixed-length octet string containing the SLH-DSA secret key, * A fixed-length octet string containing the SLH-DSA secret key
whose length depends on the algorithm ID as specified in Table 8. whose length depends on the algorithm ID as specified in Table 8.
7. Notes on Algorithms 7. Notes on Algorithms
7.1. Symmetric Algorithms for SEIPD Packets 7.1. Symmetric Algorithms for SEIPD Packets
Implementations MUST implement AES-256. An implementation SHOULD use Implementations MUST implement AES-256. An implementation SHOULD use
AES-256 in the case of a v1 Symmetrically Encrypted and Integrity AES-256 in the case of a v1 Symmetrically Encrypted Integrity
Protected Data (SEIPD) packet, or AES-256 with any available AEAD Protected Data (SEIPD) packet or AES-256 with any available
mode in the case of a v2 SEIPD packet, if all recipient certificates Authenticated Encryption with Associated Data (AEAD) mode in the case
indicate support for it (explicitly or implicitly). This requirement of a v2 SEIPD packet, if all recipient certificates indicate support
is not specified as a MUST, because it would render messages not for it (explicitly or implicitly). This requirement is not specified
using AES-256 invalid and subject to rejection upon decryption; as a MUST because it would render messages not using AES-256 invalid
however, a receiving implementation may not have access to all and subject to rejection upon decryption; however, a receiving
recipient certificates and therefore cannot reliably enforce such a implementation may not have access to all recipient certificates and,
requirement. therefore, cannot reliably enforce such a requirement.
A certificate that contains a PQ(/T) key SHOULD include AES-256 in A certificate that contains a PQ(/T) key SHOULD include AES-256 in
the "Preferred Symmetric Ciphers for v1 SEIPD" subpacket and SHOULD the "Preferred Symmetric Ciphers for v1 SEIPD" subpacket and SHOULD
include the pair AES-256 with OCB in the "Preferred AEAD include the pair AES-256 with OCB in the "Preferred AEAD
Ciphersuites" subpacket to make support for AES-256 and AES-256 with Ciphersuites" subpacket to make support for AES-256 and AES-256 with
OCB explicit. OCB explicit.
If AES-256 is not explicitly in the list of the "Preferred Symmetric If AES-256 is not explicitly in the list of the "Preferred Symmetric
Ciphers for v1 SEIPD" subpacket, and if the certificate contains a Ciphers for v1 SEIPD" subpacket, and if the certificate contains a
PQ(/T) key, it is implicitly at the end of the list. This is PQ(/T) key, it is implicitly at the end of the list. This is
justified since AES-256 is mandatory to implement. If AES-128 is justified since AES-256 is mandatory to implement. If AES-128 is
also implicitly added to the list, it is added after AES-256. also implicitly added to the list, it is added after AES-256.
If the pair AES-256 with OCB is not explicitly in the list of the If the pair of AES-256 and OCB is not explicitly in the list of the
"Preferred AEAD Ciphersuites" subpacket, and if the certificate "Preferred AEAD Ciphersuites" subpacket, and if the certificate
contains a PQ(/T) key, it is implicitly at the end of the list. This contains a PQ(/T) key, it is implicitly at the end of the list. This
is justified since AES-256 and OCB are mandatory to implement. If is justified since AES-256 and OCB are mandatory to implement. If
the pair AES-128 with OCB is also implicitly added to the list, it is the pair of AES-128 and OCB is also implicitly added to the list, it
added after the pair AES-256 with OCB. is added after the pair of AES-256 and OCB.
7.2. Hash Algorithms for Key Binding Signatures 7.2. Hash Algorithms for Key Binding Signatures
Subkey binding signatures (Signature Type 0x18) over algorithms Subkey binding signatures (Signature Type 0x18) over algorithms
described in this document MUST NOT be made with MD5, SHA-1, or described in this document MUST NOT be made with MD5, SHA-1, or
RIPEMD-160. A receiving implementation MUST treat such a signature RIPEMD-160. A receiving implementation MUST treat such a signature
as invalid. as invalid.
8. Migration Considerations 8. Migration Considerations
The post-quantum KEM algorithms defined in Table 2 and the signature The post-quantum KEM algorithms defined in Table 2 and the signature
algorithms defined in Table 1 are a set of new public key algorithms algorithms defined in Table 1 are a set of new public key algorithms
that extend the algorithm selection of [RFC9580]. During the that extend the algorithm selection of [RFC9580]. During the
transition period, the post-quantum algorithms will not be supported transition period, the post-quantum algorithms will not be supported
by all clients. Therefore, various migration considerations must be by all clients. Therefore, various migration considerations must be
taken into account, in particular backwards compatibility to existing taken into account particularly backwards compatibility to existing
implementations that have not yet been updated to support the post- implementations that have not yet been updated to support the post-
quantum algorithms. quantum algorithms.
8.1. Encrypting to Traditional and PQ(/T) Keys 8.1. Encrypting to Traditional and PQ(/T) Keys
During the transition to post-quantum cryptography, an implementation During the transition to post-quantum cryptography, an implementation
MAY, by default, encrypt messages to both PQ(/T) and traditional keys MAY, by default, encrypt messages to both PQ(/T) and traditional keys
to avoid disruption to communications, optionally displaying a to avoid disruption to communications, optionally displaying a
warning. As noted in Section 3.1, the confidentiality of a message warning. As noted in Section 3.1, the confidentiality of a message
is not post-quantum secure when using multiple PKESKs unless all of is not post-quantum secure when using multiple PKESKs unless all of
them use PQ(/T) encryption schemes. them use PQ(/T) encryption schemes.
8.2. Signing with Traditional and PQ(/T) Keys 8.2. Signing with Traditional and PQ(/T) Keys
The OpenPGP specification [RFC9580] allows signing a message with The OpenPGP specification [RFC9580] allows signing a message with
multiple signatures. This implies the possibility to sign with both multiple signatures. This implies the possibility of signing with
a PQ(/T) and a traditional key as described in Section 3.3. Note both a PQ(/T) and a traditional key as described in Section 3.3.
that signing only with PQ(/T) key material is not backwards Note that signing with only PQ(/T) key material is not backwards
compatible. compatible.
8.3. Verifying with Traditional and PQ(/T) Keys 8.3. Verifying with Traditional and PQ(/T) Keys
When verifying, an implementation MAY be willing to accept signatures When verifying, an implementation MAY be willing to accept signatures
both from PQ(/T) keys and from traditional keys. A verifier both from PQ(/T) keys and from traditional keys. A verifier
concerned with a cryptographically relevant quantum computer with concerned with a cryptographically relevant quantum computer with
knowledge of a peer that has a PQ(/T) signing key MAY prefer instead knowledge of a peer that has a PQ(/T) signing key MAY instead prefer
to ignore all traditional signatures from that peer. to ignore all traditional signatures from that peer.
8.4. Generating PQ(/T) Keys 8.4. Generating PQ(/T) Keys
It is RECOMMENDED to generate fresh secrets when generating PQ(/T) It is RECOMMENDED to generate fresh secrets when generating PQ(/T)
keys. Note that reusing key material from existing ECC keys in keys. Note that reusing key material from existing ECC keys in
PQ(/T) keys does not provide backwards compatibility. PQ(/T) keys does not provide backwards compatibility.
9. Security Considerations 9. Security Considerations
9.1. Security Aspects of Composite Signatures 9.1. Security Aspects of Composite Signatures
When multiple signatures are applied to a message, the question of When multiple signatures are applied to a message, the question of
the protocol's resistance against signature stripping attacks the protocol's resistance against signature-stripping attacks
naturally arises. In a signature stripping attack, an adversary naturally arises. In a signature-stripping attack, an adversary
removes one or more of the signatures such that only a subset of the removes one or more of the signatures such that only a subset of the
signatures remain in the message at the point when it is verified. signatures remain in the message at the point when it is verified.
This amounts to a downgrade attack that potentially reduces the value This amounts to a downgrade attack that potentially reduces the value
of the signature. It should be noted that the composite signature of the signature. It should be noted that the composite signature
schemes specified in this draft are not subject to a signature schemes specified in this document are not subject to a signature-
stripping vulnerability. This is due to the fact that in any OpenPGP stripping vulnerability. This is due to the fact that, in any
signature, the hashed metadata includes the signature algorithm ID, OpenPGP signature, the hashed metadata includes the signature
as specified in Section 5.2.4 of [RFC9580]. As a consequence, a algorithm ID, as specified in Section 5.2.4 of [RFC9580]. As a
component signature taken out of the context of a specific composite consequence, a component signature taken out of the context of a
algorithm is not a valid OpenPGP signature for any message. specific composite algorithm is not a valid OpenPGP signature for any
message.
An attacker cannot generate a fresh valid signature for a message An attacker cannot generate a fresh valid signature for a message
that has already been signed twice with the composite algorithm; that has already been signed twice with the composite algorithm;
being able to do so would violate Strong Unforgeability under Chosen being able to do so would violate Strong Unforgeability under Chosen
Message Attack (SUF-CMA). Specifically, an attacker might try to Message Attack (SUF-CMA). Specifically, an attacker might try to
construct a new signature by remixing the component parts of two construct a new signature by remixing the component parts of two
legitimate composite signatures. That is impossible because each v6 legitimate composite signatures. That is impossible because each v6
signature embeds a random salt at the start of its hashed metadata. signature embeds a random salt at the start of its hashed metadata.
The two legitimate signatures use different salts, so their The two legitimate signatures use different salts, so their
components are not interchangeable and cannot be recombined into a components are not interchangeable and cannot be recombined into a
valid signature. valid signature.
9.1.1. Preventing Signature Cross-Protocol Attacks 9.1.1. Preventing Signature Cross-Protocol Attacks
Signature cross-protocol attacks exploit the reuse of signatures Signature cross-protocol attacks exploit the reuse of signatures
across different protocols or contexts, allowing attackers to across different protocols or contexts, allowing attackers to
maliciously repurpose valid signatures in unintended ways. ML-DSA maliciously repurpose valid signatures in unintended ways. ML-DSA
[FIPS-204], SLH-DSA [FIPS-205], and EdDSA [RFC8032] support an [FIPS-204], SLH-DSA [FIPS-205], and EdDSA [RFC8032] support an
optional context string parameter ctx that can be incorporated into optional context string parameter ctx that can be incorporated into
the algorithm's internal message preprocessing step before signing the algorithm's internal message preprocessing step before signing
and verification. This context parameter can in principle contribute and verification. In principle, this context parameter can
to the prevention of cross-protocol attacks. Nevertheless, this contribute to the prevention of cross-protocol attacks.
specification defines all these algorithms to use an empty context Nevertheless, this specification defines all these algorithms to use
string which is in accordance with the previous use of EdDSA in an empty context string, which is in accordance with the previous use
OpenPGP, and maximizes interoperability with cryptographic libraries. of EdDSA in OpenPGP and maximizes interoperability with cryptographic
In order to reliably prevent cross-protocol attacks, this libraries. In order to reliably prevent cross-protocol attacks, this
specification recommends avoiding key-reuse across protocols in specification recommends avoiding key-reuse across protocols in
Section 8.4. Section 8.4.
9.2. Key Combiner 9.2. Key Combiner
A central security notion of a key combiner is IND-CCA2-security. It A central security notion of a key combiner is IND-CCA2-security. It
is argued in [BCD_24] that the key combiner specified in is argued in [BCD_24] that the key combiner specified in
Section 4.2.1 is IND-CCA2-secure if ML-KEM is IND-CCA2-secure or the Section 4.2.1 is IND-CCA2-secure if ML-KEM is IND-CCA2-secure or the
Strong Diffie-Hellman problem in a nominal group holds. Note that Strong Diffie-Hellman problem in a nominal group holds. Note that
Curve25519 and Curve448 qualify as such nominal groups [ABH_21]. Curve25519 and Curve448 qualify as such nominal groups [ABH_21].
Note that the inclusion of the ECC public key in the key combiner Note that the inclusion of the ECC public key in the key combiner
also accounts for multi-target attacks against X25519 and X448. also accounts for multi-target attacks against X25519 and X448.
9.2.1. Domain Separation and Context Binding 9.2.1. Domain Separation and Context Binding
The domSep information defined in Section 4.2.1 provides the domain The domSep information defined in Section 4.2.1 provides the domain
separation for the key combiner construction. This ensures that the separation for the key-combiner construction. This ensures that the
input keying material is used to generate a KEK for a specific input keying material is used to generate a KEK for a specific
purpose. Appending the length octet ensures that no collisions can purpose. Appending the length octet ensures that no collisions can
result across different domains, which might be defined in the result across different domains, which might be defined in the
future. This is because domSep || len(domSep) is guaranteed to future. This is because domSep || len(domSep) is guaranteed to
result in a suffix-free set of octet strings even if further values result in a suffix-free set of octet strings even if further values
should be defined for domSep. The term "suffix-free" applied to a should be defined for domSep. The term "suffix-free" applied to a
set of words indicates that no word is the suffix of another. Thus, set of words indicates that no word is the suffix of another. Thus,
this property ensures unambiguous parsing of a word from the rear of this property ensures unambiguous parsing of a word from the rear of
a string. Unambiguous parseability, in turn, ensures that no a string. Unambiguous parseability, in turn, ensures that no
collisions can happen on the space of input strings to the key collisions can happen on the space of input strings to the key
combiner. combiner.
The algorithm ID, passed as the algID parameter to multiKeyCombine, The algorithm ID, passed as the algID parameter to multiKeyCombine,
binds the derived KEK to the chosen algorithm. The algorithm ID binds the derived KEK to the chosen algorithm. The algorithm ID
identifies unequivocally the algorithm, the parameters for its unequivocally identifies the algorithm, the parameters for its
instantiation, and the length of all artifacts, including the derived instantiation, and the length of all artifacts, including the derived
key. key.
9.3. ML-DSA and SLH-DSA Hedged Variants 9.3. ML-DSA and SLH-DSA Hedged Variants
This specification makes use of the default "hedged" variants of ML- This specification makes use of the default "hedged" variants of ML-
DSA and SLH-DSA, which mix fresh randomness into the respective DSA and SLH-DSA, which mix fresh randomness into the respective
signature-generation algorithm's internal hashing step. This has the signature-generation algorithm's internal hashing step. This has the
advantage of an enhanced side-channel resistance of the signature advantage of an enhanced side-channel resistance of the signature
operations according to [FIPS-204] and [FIPS-205]. operations according to [FIPS-204] and [FIPS-205].
9.4. Minimum Digest Size for PQ(/T) Signatures 9.4. Minimum Digest Size for PQ(/T) Signatures
This specification requires that all PQ(/T) signatures defined in This specification requires that all PQ(/T) signatures defined in
this document are made on message digests computed with a hash this document are made on message digests computed with a hash
algorithm with at least 256 bits of digest size. Since all signature algorithm with at least 256 bits of digest size. Since all signature
algorithms defined in this document require version 6 (or newer) algorithms defined in this document require version 6 (or newer)
signature packets, which currently include a leading random salt signature packets, which currently include a leading random salt
value in the hashed data, the required property is not collision but value in the hashed data, the required property is not collision but
(2nd) preimage resistance. Therefore, a hash algorithm with a digest (second) preimage resistance. Therefore, a hash algorithm with a
size of at least 256 bits is sufficient to match the targeted digest size of at least 256 bits is sufficient to match the targeted
security levels of all PQ(/T) algorithms defined in this document. security levels of all PQ(/T) algorithms defined in this document.
9.5. Symmetric Algorithms for SEIPD Packets 9.5. Symmetric Algorithms for SEIPD Packets
This specification mandates support for AES-256 for two reasons. This specification mandates support for AES-256 for two reasons.
First, AES-KeyWrap with AES-256 is already part of the composite KEM First, AES-KeyWrap with AES-256 is already part of the composite KEM
construction. Second, some of the PQ(/T) algorithms target the construction. Second, some of the PQ(/T) algorithms target the
security level of AES-256. security level of AES-256.
For the same reasons, this specification further recommends the use For the same reasons, this specification further recommends the use
of AES-256 if it is supported by all recipient certificates, of AES-256 if it is supported by all recipient certificates,
regardless of what the implementation would otherwise choose based on regardless of what the implementation would otherwise choose based on
the recipients' preferences. This recommendation should be the recipients' preferences. This recommendation should be
understood as a clear and simple rule for the selection of AES-256 understood as a clear and simple rule for the selection of AES-256
for encryption. Implementations may also make more nuanced for encryption. Implementations may also make more nuanced
decisions. decisions.
9.6. Key Generation 9.6. Key Generation
When generating keys, this specification requires component keys to When generating keys, this specification requires component keys to
be generated independently, and recommends not to reuse existing keys be generated independently and recommends not reusing existing keys
for any of the components. Note that reusing a key across different for any of the components. Note that reusing a key across different
protocols may lead to signature confusion vulnerabilities, that protocols may lead to signature confusion vulnerabilities that
formally classify as signature forgeries. Generally, reusing a key formally classify as signature forgeries. Generally, reusing a key
for different purposes may lead to subtle vulnerabilities. for different purposes may lead to subtle vulnerabilities.
9.7. Random Number Generation and Seeding 9.7. Random Number Generation and Seeding
As mandated by Section 13.10 of [RFC9580], all random data must be As mandated by Section 13.10 of [RFC9580], all random data must be
generated using a cryptographically secure pseudorandom number generated using a Cryptographically Secure Pseudorandom Number
generator (CSPRNG). Generator (CSPRNG).
10. Additional Considerations 10. Additional Considerations
10.1. Performance Considerations for SLH-DSA 10.1. Performance Considerations for SLH-DSA
This specification introduces both ML-DSA + EdDSA as well as SLH-DSA This specification introduces both ML-DSA + EdDSA and SLH-DSA as
as PQ(/T) signature schemes. PQ(/T) signature schemes.
Generally, it can be said that ML-DSA + EdDSA provides a performance Generally, ML-DSA + EdDSA provides a performance in terms of
in terms of execution time requirements that is close to that of execution time requirements that is close to that of traditional ECC
traditional ECC signature schemes. Regarding the size of signatures signature schemes. Regarding the size of signatures and public keys,
and public keys, though, ML-DSA has far greater requirements than though, ML-DSA has far greater requirements than traditional schemes
traditional schemes like ECC-based or even RSA signature schemes. like ECC-based or even RSA signature schemes.
Implementers may want to offer SLH-DSA for applications where the Implementers may want to offer SLH-DSA for applications where the
weaker security assumptions of a hash-based signature scheme are weaker security assumptions of a hash-based signature scheme are
required - namely only the 2nd preimage resistance of a hash function required -- namely only the second preimage resistance of a hash
- and thus a potentially higher degree of trust in the long-term function; thus, a potentially higher degree of trust in the long-term
security of signatures is achieved. However, SLH-DSA has performance security of signatures is achieved. However, SLH-DSA has performance
characteristics in terms of execution time of the signature characteristics in terms of execution time of the signature
generation as well as space requirements for the signature that are generation as well as space requirements for the signature that are
even greater than those of ML-DSA + EdDSA signature schemes. even greater than those of ML-DSA + EdDSA signature schemes.
Pertaining to the execution time, the particularly costly operation Pertaining to the execution time, the particularly costly operation
in SLH-DSA is the signature generation. Depending on the parameter in SLH-DSA is the signature generation. Depending on the parameter
set, it can range from approximately one hundred to more than two set, it can range from approximately one hundred to more than two
thousand times that of ML-DSA-87. These numbers are based on the thousand times that of ML-DSA-87. These numbers are based on the
performance measurements published in the NIST submissions for SLH- performance measurements published in the NIST submissions for SLH-
skipping to change at page 30, line 10 skipping to change at line 1323
the algorithm SLH-DSA-SHAKE-128f ("f" standing for "fast") should be the algorithm SLH-DSA-SHAKE-128f ("f" standing for "fast") should be
chosen. This comes at the expense of a larger signature size. This chosen. This comes at the expense of a larger signature size. This
choice can be relevant in applications where mass signing occurs or a choice can be relevant in applications where mass signing occurs or a
small latency is required. small latency is required.
In order to minimize the space requirements of an SLH-DSA signature, In order to minimize the space requirements of an SLH-DSA signature,
an algorithm ID with the name ending in "s" for "small" should be an algorithm ID with the name ending in "s" for "small" should be
chosen. This comes at the expense of a longer signature generation chosen. This comes at the expense of a longer signature generation
time. In particular, SLH-DSA-SHAKE-128s achieves the smallest time. In particular, SLH-DSA-SHAKE-128s achieves the smallest
possible signature size, which is about the double size of an ML- possible signature size, which is about the double size of an ML-
DSA-87 signature. Where a higher security level than 128 bit is DSA-87 signature. Where a higher security level than 128 bits is
needed, SLH-DSA-SHAKE-256s can be used. needed, SLH-DSA-SHAKE-256s can be used.
Unlike the signature generation time, the signature verification time Unlike the signature generation time, the signature verification time
of SLH-DSA is not that much larger than that of other PQC schemes. of SLH-DSA is not that much larger than that of other PQC schemes.
Based on the performance measurements published in the NIST Based on the performance measurements published in the NIST
submissions for SLH-DSA and ML-DSA, the verification time of SLH-DSA submissions for SLH-DSA and ML-DSA, the verification time of SLH-DSA
is, for the parameters covered by this specification, larger than is, for the parameters covered by this specification, larger than
that of ML-DSA-87 by a factor ranging from four (for -128s) over nine that of ML-DSA-87 by a factor ranging from four (for -128s) over nine
(for -256s) to twelve (for -128f). (for -256s) to twelve (for -128f).
11. IANA Considerations 11. IANA Considerations
IANA is requested to add the algorithm IDs defined in Table 9 to the IANA has added the algorithm IDs defined in Table 9 to the "OpenPGP
existing registry OpenPGP Public Key Algorithms maintained at Public Key Algorithms" registry at [IANA-OPENPGP].
[IANA-OPENPGP].
+=======+==========+=======+=======+=========+============+=========+ +==+==========+==========+=========+===========+===========+=========+
|ID |Algorithm | Public| Secret|Signature| PKESK|Reference| |ID|Algorithm |Public Key| Secret| Signature| PKESK|Reference|
| | | Key| Key| Format| Format| | | | | Format| Key| Format| Format| |
| | | Format| Format| | | | | | | | Format| | | |
+=======+==========+=======+=======+=========+============+=========+ +==+==========+==========+=========+===========+===========+=========+
|TBD(30)|ML-DSA- | 32| 32|64 octets| N/A| Section| |30|ML-DSA- | 32-octet| 32-octet| 64-octet| N/A| Section|
| |65+Ed25519| octets| octets| Ed25519| | 5.2 of| | |65+Ed25519| Ed25519| Ed25519| Ed25519| | 5.2 of|
| | |Ed25519|Ed25519|signature| | RFC TBD| | | |public key| secret| signature| | RFC 9980|
| | | public| secret| (Table| | | | | |(Table 6),| key| (Table 6),| | |
| | | key| key| 6), 3309| | | | | |1952-octet| (Table| 3309-octet| | |
| | | (Table| (Table| octets| | | | | | ML-DSA-65| 6),| ML-DSA-65| | |
| | | 6),| 6), 32|ML-DSA-65| | | | | |public key| 32-octet| signature| | |
| | | 1952| octets|signature| | | | | | (Table 7)|ML-DSA-65| (Table 7)| | |
| | | octets| ML-|(Table 7)| | | | | | | secret| | | |
| | | ML-| DSA-65| | | | | | | | key| | | |
| | | DSA-65| secret| | | | | | | |(Table 7)| | | |
| | | public| key| | | | +--+----------+----------+---------+-----------+-----------+---------+
| | | key| (Table| | | | |31|ML-DSA- | 57-octet| 57-octet| 114-octet| N/A| Section|
| | | (Table| 7)| | | | | |87+Ed448 | Ed448| Ed448| Ed448| | 5.2 of|
| | | 7)| | | | | | | |public key| secret| signature| | RFC 9980|
+-------+----------+-------+-------+---------+------------+---------+ | | |(Table 6),| key| (Table 6),| | |
|TBD(31)|ML-DSA- | 57| 57| 114| N/A| Section| | | |2592-octet| (Table| 4627-octet| | |
| |87+Ed448 | octets| octets| octets| | 5.2 of| | | | ML-DSA-87| 6),| ML-DSA-87| | |
| | | Ed448| Ed448| Ed448| | RFC TBD| | | |public key| 32-octet| signature| | |
| | | public| secret|signature| | | | | | (Table 7)|ML-DSA-87| (Table 7)| | |
| | | key| key| (Table| | | | | | | secret| | | |
| | | (Table| (Table| 6), 4627| | | | | | | key| | | |
| | | 6),| 6), 32| octets| | | | | | |(Table 7)| | | |
| | | 2592| octets|ML-DSA-87| | | +--+----------+----------+---------+-----------+-----------+---------+
| | | octets| ML-|signature| | | |32|SLH-DSA- | 32-octet| 64-octet| 7856-octet| N/A| Section|
| | | ML-| DSA-87|(Table 7)| | | | |SHAKE-128s|public key| secret| signature| | 6.1 of|
| | | DSA-87| secret| | | | | | | (Table 8)| key| (Table 8)| | RFC 9980|
| | | public| key| | | | | | | |(Table 8)| | | |
| | | key| (Table| | | | +--+----------+----------+---------+-----------+-----------+---------+
| | | (Table| 7)| | | | |33|SLH-DSA- | 32-octet| 64-octet|17088-octet| N/A| Section|
| | | 7)| | | | | | |SHAKE-128f|public key| secret| signature| | 6.1 of|
+-------+----------+-------+-------+---------+------------+---------+ | | | (Table 8)| key| (Table 8)| | RFC 9980|
|TBD(32)|SLH-DSA- | 32| 64| 7856| N/A| Section| | | | |(Table 8)| | | |
| |SHAKE-128s| octets| octets| octets| | 6.1 of| +--+----------+----------+---------+-----------+-----------+---------+
| | | public| secret|signature| | RFC TBD| |34|SLH-DSA- | 64-octet|128-octet|29792-octet| N/A| Section|
| | | key| key|(Table 8)| | | | |SHAKE-256s|public key| secret| signature| | 6.1 of|
| | | (Table| (Table| | | | | | | (Table 8)| key| (Table 8)| | RFC 9980|
| | | 8)| 8)| | | | | | | |(Table 8)| | | |
+-------+----------+-------+-------+---------+------------+---------+ +--+----------+----------+---------+-----------+-----------+---------+
|TBD(33)|SLH-DSA- | 32| 64| 17088| N/A| Section| |35|ML-KEM- | 32-octet| 32-octet| N/A| 32-octet| Section|
| |SHAKE-128f| octets| octets| octets| | 6.1 of| | |768+X25519| X25519| X25519| | X25519| 4.2 of|
| | | public| secret|signature| | RFC TBD| | | |public key| secret| |ciphertext,| RFC 9980|
| | | key| key|(Table 8)| | | | | |(Table 3),| key| | 1088-octet| |
| | | (Table| (Table| | | | | | |1184-octet| (Table| | ML-KEM-768| |
| | | 8)| 8)| | | | | | |ML-KEM-768| 3),| |ciphertext,| |
+-------+----------+-------+-------+---------+------------+---------+ | | |public key| 64-octet| | 1 octet| |
|TBD(34)|SLH-DSA- | 64| 128| 29792| N/A| Section| | | | (Table 4)| ML-| | remaining| |
| |SHAKE-256s| octets| octets| octets| | 6.1 of| | | | | KEM-768| | length, [1| |
| | | public| secret|signature| | RFC TBD| | | | | secret| | octet| |
| | | key| key|(Table 8)| | | | | | | key| | algorithm| |
| | | (Table| (Table| | | | | | | |(Table 4)| | ID in case| |
| | | 8)| 8)| | | | | | | | | | of v3| |
+-------+----------+-------+-------+---------+------------+---------+ | | | | | | PKESK,] n| |
|TBD(35)|ML-KEM- | 32| 32| N/A| 32 octets| Section| | | | | | | octets| |
| |768+X25519| octets| octets| | X25519| 4.2 of| | | | | | | wrapped| |
| | | X25519| X25519| | ciphertext,| RFC TBD| | | | | | |session key| |
| | | public| secret| | 1088 octets| | | | | | | | (Section| |
| | | key| key| | ML-KEM-768| | | | | | | | 4.3.1)| |
| | | (Table| (Table| | ciphertext,| | +--+----------+----------+---------+-----------+-----------+---------+
| | | 3),| 3), 64| | 1 octet| | |36|ML-KEM- | 56-octet| 56-octet| N/A| 56-octet| Section|
| | | 1184| octets| | remaining| | | |1024+X448 | X448| X448| | X448| 4.2 of|
| | | octets| ML-| | length, [1| | | | |public key| secret| |ciphertext,| RFC 9980|
| | | ML-|KEM-768| | octet| | | | |(Table 3),| key| | 1568-octet| |
| | |KEM-768|secret-| | algorithm| | | | |1568-octet| (Table| |ML-KEM-1024| |
| | | public| key| | ID in case| | | | | ML-| 3),| |ciphertext,| |
| | | key| (Table| | of v3| | | | | KEM-1024| 64-octet| | 1 octet| |
| | | (Table| 4)| | PKESK,] n| | | | |public key| ML-| | remaining| |
| | | 4)| | | octets| | | | | (Table 4)| KEM-1024| | length, [1| |
| | | | | | wrapped| | | | | | secret| | octet| |
| | | | | | session key| | | | | | key| | algorithm| |
| | | | | | (Section| | | | | |(Table 4)| | ID in case| |
| | | | | | 4.3.1)| | | | | | | | of v3| |
+-------+----------+-------+-------+---------+------------+---------+ | | | | | | PKESK,] n| |
|TBD(36)|ML-KEM- | 56| 56| N/A| 56 octets| Section| | | | | | | octets| |
| |1024+X448 | octets| octets| | X448| 4.2 of| | | | | | | wrapped| |
| | | X448| X448| | ciphertext,| RFC TBD| | | | | | |session key| |
| | | public| secret| | 1568 octets| | | | | | | | (Section| |
| | | key| key| | ML-KEM-1024| | | | | | | | 4.3.1)| |
| | | (Table| (Table| | ciphertext,| | +--+----------+----------+---------+-----------+-----------+---------+
| | | 3),| 3), 64| | 1 octet| |
| | | 1568| octets| | remaining| |
| | | octets|ML-KEM-| | length, [1| |
| | |ML-KEM-| 1024| | octet| |
| | | 1024|secret-| | algorithm| |
| | | public| key| | ID in case| |
| | | key| (Table| | of v3| |
| | | (Table| 4)| | PKESK,] n| |
| | | 4)| | | octets| |
| | | | | | wrapped| |
| | | | | | session key| |
| | | | | | (Section| |
| | | | | | 4.3.1)| |
+-------+----------+-------+-------+---------+------------+---------+
Table 9: IANA updates for registry 'OpenPGP Public Key Algorithms' Table 9: Updates to the "OpenPGP Public Key Algorithms" Registry
IANA is asked to add the following note to this registry: IANA has added the following note to this registry:
The field specifications enclosed in square brackets for PKESK The field specifications enclosed in square brackets for PKESK
Format represent fields that may or may not be present, depending Format represent fields that may or may not be present, depending
on the PKESK version. on the PKESK version.
12. Changelog 12. References
12.1. draft-wussler-openpgp-pqc-01
* Shifted the algorithm IDs by 4 to align with the crypto-refresh.
* Renamed v5 packets into v6 to align with the crypto-refresh.
* Defined IND-CCA2 security for KDF and key combination.
* Added explicit key generation procedures.
* Changed the key combination KMAC salt.
* Mandated Parameter ID check in SPHINCS+ signature verification.
* Fixed key share size for Kyber-768.
* Added "Preliminaries" section.
* Fixed IANA considerations.
12.2. draft-wussler-openpgp-pqc-02
* Added the ephemeral and public key in the ECC key derivation
function.
* Removed public key hash from key combiner.
* Allowed v3 PKESKs and v4 keys with PQ algorithms, limiting them to
AES symmetric ciphers. for encryption with SEIPDv1, in line with
the crypto-refresh.
12.3. draft-wussler-openpgp-pqc-03
* Replaced round 3 submission with NIST PQC Draft Standards FIPS
203, 204, 205.
* Added consideration about security level for hashes.
12.4. draft-wussler-openpgp-pqc-04
* Added Johannes Roth as author
12.5. draft-ietf-openpgp-pqc-00
* Renamed draft
12.6. draft-ietf-openpgp-pqc-01
* Mandated AES-256 as mandatory to implement.
* Added AES-256 / AES-128 with OCB implicitly to v1/v2 SEIPD
preferences of "PQ(/T) certificates".
* Added a recommendation to use AES-256 when possible.
* Swapped the optional v3 PKESK algorithm identifier with length
octet in order to align with X25519 and X448.
* Fixed ML-DSA secret key size.
* Added test vectors.
* Correction and completion of IANA instructions.
12.7. draft-ietf-openpgp-pqc-02
* Removed git rebase artifact.
12.8. draft-ietf-openpgp-pqc-03
* Updated SLH-DSA by removing parametrization and restricting to
three SLH-DSA-SHAKE algorithm code points.
* Removed NIST and Brainpool curve hybrids, dropped ECDSA from the
current specification.
* Updated KDF as proposed at IETF 119.
* Removed whitespaces from composite algorithm names.
* Explicitly disallowed SED (Packet Type ID 9) and weak hashes when
using PQ algorithms.
12.9. draft-ietf-openpgp-pqc-04
* Fixed ML-DSA signature size.
* Fixed parameters order in PKESK description.
* Fixed missing inputs into KEM combination description.
* Improved parallel encryption guidance.
* Improved SED deprecation description.
* Added ML-DSA test vectors.
12.10. draft-ietf-openpgp-pqc-05
* Reworked KEM combiner for the purpose of NIST-compliance.
* Mandated v6 keys for ML-KEM + ECDH algorithms.
* Defined secret key seed format for ML-KEM and ML-DSA.
* Added key generation security considerations.
* Replaced initial public drafts with FIPS 203, 204, 205.
12.11. draft-ietf-openpgp-pqc-06
* Fixed and improved test vectors.
12.12. draft-ietf-openpgp-pqc-07
* Assigned code points 30 - 34 for ML-DSA + EdDSA and SLH-DSA
algorithms.
* Aligned KEM combiner with LAMPS.
* Dropped CCA-conversion of X25519/X448 and adjusted security
considerations.
* Switched to hedged variant also for SLH-DSA.
12.13. draft-ietf-openpgp-pqc-08
* Assigned code points 35 and 36 for ML-KEM + ECDH algorithms.
* Removed hash binding for ML-DSA + EdDSA and SLH-DSA algorithms.
* Allowed usage of ML-KEM-768 + X25519 with v4 keys.
* Aligned KEM combiner to X-Wing and switched to suffix-free
encoding of the domain separator.
12.14. draft-ietf-openpgp-pqc-09
* Removed subkey semantics related guidance.
* Updated test vectors.
* Added non-normative algorithm explanation.
12.15. draft-ietf-openpgp-pqc-10
* Specified minimum requirements for signature message digest sizes.
* Added security considerations for signature message digest sizes.
12.16. draft-ietf-openpgp-pqc-11
* Editorial changes and fixes of inconsistencies.
12.17. draft-ietf-openpgp-pqc-12
* Moved from informational to standards-track.
12.18. draft-ietf-openpgp-pqc-13
* Addressed various editorial comments from AD review.
* Added text about signature verification to the migration
considerations section.
* Added text about preventing signature cross-protocol attacks to
the security considerations section.
12.19. draft-ietf-openpgp-pqc-14
* Fixed a broken reference.
* Updated KEM combiner references.
12.20. draft-ietf-openpgp-pqc-15
* Addressed various editorial comments from IESG reviews.
12.21. draft-ietf-openpgp-pqc-16
* Addressed more editorial comments from IESG reviews.
13. Contributors
Stephan Ehlen (BSI)
Carl-Daniel Hailfinger (BSI)
Andreas Huelsing (TU Eindhoven)
Acknowledgments
Thanks to Daniel Kahn Gillmor, Justus Winter, Daniel Huigens,
Evangelos Karatsiolis, and early implementers of the draft for their
reviews and feedback on this document.
References
Normative References 12.1. Normative References
[FIPS-203] National Institute of Standards and Technology, "Module- [FIPS-203] NIST, "Module-Lattice-Based Key-Encapsulation Mechanism
Lattice-Based Key-Encapsulation Mechanism Standard", Standard", NIST FIPS 203, DOI 10.6028/NIST.FIPS.203,
August 2024, <https://doi.org/10.6028/NIST.FIPS.203>. August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.203.pdf>.
[FIPS-204] National Institute of Standards and Technology, "Module- [FIPS-204] NIST, "Module-Lattice-Based Digital Signature Standard",
Lattice-Based Digital Signature Standard", August 2024, NIST FIPS 204, DOI 10.6028/NIST.FIPS.204, August 2024,
<https://doi.org/10.6028/NIST.FIPS.204>. <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.204.pdf>.
[FIPS-205] National Institute of Standards and Technology, "Stateless [FIPS-205] NIST, "Stateless Hash-Based Digital Signature Standard",
Hash-Based Digital Signature Standard", August 2024, NIST FIPS 205, DOI 10.6028/NIST.FIPS.205, August 2024,
<https://doi.org/10.6028/NIST.FIPS.205>. <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.205.pdf>.
[IANA-OPENPGP] [IANA-OPENPGP]
IANA, "OpenPGP Public Key Algorithms", n.d., IANA, "OpenPGP Public Key Algorithms",
<https://www.iana.org/assignments/openpgp/ <https://www.iana.org/assignments/openpgp>.
openpgp.xhtml#openpgp-public-key-algorithms>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
September 2002, <https://www.rfc-editor.org/rfc/rfc3394>. September 2002, <https://www.rfc-editor.org/info/rfc3394>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/rfc/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9580] Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe, [RFC9580] Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe,
"OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024, "OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024,
<https://www.rfc-editor.org/rfc/rfc9580>. <https://www.rfc-editor.org/info/rfc9580>.
Informative References 12.2. Informative References
[ABH_21] Alwen, J., Blanchet, B., Hauck, E., Kiltz, E., Lipp, B., [ABH_21] Alwen, J., Blanchet, B., Hauck, E., Kiltz, E., Lipp, B.,
and D. Riepel, "Analysing the HPKE Standard", 2021, and D. Riepel, "Analysing the HPKE Standard", Advances in
Cryptology – EUROCRYPT 2021, Lecture Notes in Computer
Science, vol. 12696, pp. 87-116, 2021,
<https://doi.org/10.1007/978-3-030-77870-5_4>. <https://doi.org/10.1007/978-3-030-77870-5_4>.
[BCD_24] Barbosa, M., Connolly, D., Duarte, J. D., Kaiser, A., [BCD_24] Barbosa, M., Connolly, D., Duarte, J. D., Kaiser, A.,
Schwabe, P., Varner, K., and B. Westerbaan, "X-Wing The Schwabe, P., Varner, K., and B. Westerbaan, "X-Wing The
Hybrid KEM You've Been Looking For", 2024, Hybrid KEM You've Been Looking For", IACR Communications
in Cryptology, vol. 1, no. 1, 2024,
<https://doi.org/10.62056/a3qj89n4e>. <https://doi.org/10.62056/a3qj89n4e>.
[CHHKM] Connolly, D., Hoevelmanns, K., Huelsing, A., Kousidis, S., [CHHKM] Connolly, D., Hövelmanns, K., Hülsing, A., Kousidis, S.,
and M. Meijers, "Starfighters - On the General and M. Meijers, "Starfighters - On the General
Applicability of X-Wing", Cryptology {ePrint} Archive, Applicability of X-Wing", Cryptology ePrint Archive, Paper
Paper 2025/1397 , 2025, 2025/1397, 2025, <https://eprint.iacr.org/2025/1397>.
<https://eprint.iacr.org/2025/1397>.
[NIST-PQC] Chen, L., Moody, D., and Y. Liu, "Post-Quantum [NIST-PQC] Chen, L., Moody, D., and Y. Liu, "Post-Quantum
Cryptography Standardization", December 2016, Cryptography Standardization", December 2016,
<https://csrc.nist.gov/projects/post-quantum-cryptography/ <https://csrc.nist.gov/projects/post-quantum-cryptography/
post-quantum-cryptography-standardization>. post-quantum-cryptography-standardization>.
[NISTIR-8413] [NISTIR-8413]
Alagic, G., Apon, D., Cooper, D., Dang, Q., Dang, T., Alagic, G., Apon, D., Cooper, D., Dang, Q., Dang, T.,
Kelsey, J., Lichtinger, J., Miller, C., Moody, D., Kelsey, J., Lichtinger, J., Liu, Y., Miller, C., Moody,
Peralta, R., Perlner, R., Robinson, A., Smith-Tone, D., D., Peralta, R., Perlner, R., Robinson, A., and D. Smith-
and Y. Liu, "Status Report on the Third Round of the NIST Tone, "Status Report on the Third Round of the NIST Post-
Post-Quantum Cryptography Standardization Process", NIST Quantum Cryptography Standardization Process", NIST
IR 8413 , September 2022, IR 8413-upd1, July 2022,
<https://doi.org/10.6028/NIST.IR.8413-upd1>. <https://doi.org/10.6028/NIST.IR.8413-upd1>.
[RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for [RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for
Post-Quantum Traditional Hybrid Schemes", RFC 9794, Post-Quantum Traditional Hybrid Schemes", RFC 9794,
DOI 10.17487/RFC9794, June 2025, DOI 10.17487/RFC9794, June 2025,
<https://www.rfc-editor.org/rfc/rfc9794>. <https://www.rfc-editor.org/info/rfc9794>.
Appendix A. Test Vectors Appendix A. Test Vectors
To help with implementing this specification a set of non-normative To help with implementing this specification, a set of non-normative
examples follow here. examples follow.
A.1. Sample v6 Ed25519 with ML-KEM-768+X25519 Data A.1. Sample v6 Ed25519 with ML-KEM-768+X25519 Data
A.1.1. Transferable Secret Key A.1.1. Transferable Secret Key
Here is a Transferable Secret Key consisting of: Here is a Transferable Secret Key consisting of:
* A v6 Ed25519 Private Key packet * A v6 Ed25519 Private Key packet
* A v6 direct key self-signature * A v6 direct key self-signature
skipping to change at page 66, line 37 skipping to change at line 2688
zI4fHC0TX+vYol2nOxUbPlveLv5l+mg6E0uMs5YmG49xNZigvvczzytUOOH0tWFT zI4fHC0TX+vYol2nOxUbPlveLv5l+mg6E0uMs5YmG49xNZigvvczzytUOOH0tWFT
7sQtroE5KfeaQRNBy7qxInMFPqMgczm22QmtRJKST/OfskEssZFdc6kOMzN/iWNw 7sQtroE5KfeaQRNBy7qxInMFPqMgczm22QmtRJKST/OfskEssZFdc6kOMzN/iWNw
+Evc2TxrQp53RfX4GWlJgVeBJudRMAWFzCVJ5Jx00hb3e35gvPXjpceuh0OM34Hq +Evc2TxrQp53RfX4GWlJgVeBJudRMAWFzCVJ5Jx00hb3e35gvPXjpceuh0OM34Hq
utrnRQtlISxQmw+nNwSj7q6pF8mJdGVz56Nj245gkO70G3lmNImXvWF1JsJnRTnU utrnRQtlISxQmw+nNwSj7q6pF8mJdGVz56Nj245gkO70G3lmNImXvWF1JsJnRTnU
ak/MpQwGKTcC2WrrqWhgq/WTs+8NCk5Vfa2P ak/MpQwGKTcC2WrrqWhgq/WTs+8NCk5Vfa2P
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
A.3.4. Detached Signature A.3.4. Detached Signature
Here is a detached signature for the message "Testing\n" made by the Here is a detached signature for the message "Testing\n" made by the
secret key Appendix A.3.1: secret key in Appendix A.3.1:
* A v6 signature packet * A v6 signature packet
-----BEGIN PGP SIGNATURE----- -----BEGIN PGP SIGNATURE-----
wsy1BgEeCAAAACkFgmgR5rQioQaj4uFLakk/+TD7JzIfEl6aaIAzi+n7faOuBl6m wsy1BgEeCAAAACkFgmgR5rQioQaj4uFLakk/+TD7JzIfEl6aaIAzi+n7faOuBl6m
V5MkLwAAAACrSBBfUT7vIas9dx8QHh41xBl3AgTJ/ZWeIonCLmgBizODMi0CrzXf V5MkLwAAAACrSBBfUT7vIas9dx8QHh41xBl3AgTJ/ZWeIonCLmgBizODMi0CrzXf
mPUoww+q+7XpwVfY7GuDyvoeR1fUibEW7VfV2sL8/xlYSIq7g48rENa7A/XWuwcS mPUoww+q+7XpwVfY7GuDyvoeR1fUibEW7VfV2sL8/xlYSIq7g48rENa7A/XWuwcS
JqDY1Kmb4RBmKEz8NngMftkmP6/oSey5+e6cKKsrvspxptSPHTlrd6iSUgCqSZ87 JqDY1Kmb4RBmKEz8NngMftkmP6/oSey5+e6cKKsrvspxptSPHTlrd6iSUgCqSZ87
OiHjZTVDFWf4ZBSwH0RaXIfk1Wk5OPZKYLMDpbXwqdfPustpvr2uUPkjYCM0Wwbg OiHjZTVDFWf4ZBSwH0RaXIfk1Wk5OPZKYLMDpbXwqdfPustpvr2uUPkjYCM0Wwbg
skipping to change at page 86, line 4 skipping to change at line 3615
+hA+VW/H9x4gMD9A2CE9QUWkx+X7B2N9n/cAAAAAAAAAAAAAAAAAAAAAAAAAAAAA +hA+VW/H9x4gMD9A2CE9QUWkx+X7B2N9n/cAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
BQwVHCIoMDU= BQwVHCIoMDU=
-----END PGP PUBLIC KEY BLOCK----- -----END PGP PUBLIC KEY BLOCK-----
A.4.3. Encrypted and Signed Message A.4.3. Encrypted and Signed Message
Here is a signed message "Testing\n" encrypted to the certificate Here is a signed message "Testing\n" encrypted to the certificate
Appendix A.4.2 and signed by the secret key Appendix A.4.1: Appendix A.4.2 and signed by the secret key Appendix A.4.1:
* A v6 PKESK * A v6 PKESK
* A v2 SEIPD * A v2 SEIPD
The hex-encoded mlkemKeyShare input to multiKeyCombine is The hex-encoded mlkemKeyShare input to multiKeyCombine is
f18f161e617b8ce5968f109aadea1e7e1511d10165768d36127ba913c00637d2. f18f161e617b8ce5968f109aadea1e7e1511d10165768d36127ba913c00637d2.
The hex-encoded ecdhKeyShare input to multiKeyCombine is 732860c8114a The hex-encoded ecdhKeyShare input to multiKeyCombine is
e84a964664b1f607785d11bc7d24d5324510adad89bd52db7ee0df9982ad0d1669bdd 732860c8114ae84a964664b1f607785d11bc7d24d5324510adad89bd52db7ee0df9982ad0d1669bdd05556330c86f2dae9e2edea42e05bc5.
05556330c86f2dae9e2edea42e05bc5.
The hex-encoded output of multiKeyCombine is The hex-encoded output of multiKeyCombine is
ef1e32906f67d39bc800d90cabb0033c77ca6dce8ffca3e96d9c7348e2e8c16e. ef1e32906f67d39bc800d90cabb0033c77ca6dce8ffca3e96d9c7348e2e8c16e.
The hex-encoded session key is The hex-encoded session key is
0588ce40b038aac353d1cf8c67a674b412985105794821013ef154f786c4d89d. 0588ce40b038aac353d1cf8c67a674b412985105794821013ef154f786c4d89d.
-----BEGIN PGP MESSAGE----- -----BEGIN PGP MESSAGE-----
wcXlBiEGZQkOFHqBFqt/YqtOx6rlnZ5lMv6yryMMc83IafvGDI8k+1L82B20zVhA wcXlBiEGZQkOFHqBFqt/YqtOx6rlnZ5lMv6yryMMc83IafvGDI8k+1L82B20zVhA
skipping to change at page 271, line 21 skipping to change at line 12508
UY+p+jspaT2iD+/hhDrh2qFL6Ss6D7xe4tq7GCL9xJAgx/pMlKHX5rPtGAXCc0Wi UY+p+jspaT2iD+/hhDrh2qFL6Ss6D7xe4tq7GCL9xJAgx/pMlKHX5rPtGAXCc0Wi
Z4Qt845BWyZ8WPXJYNygD09DswqHng5XAVjGuz2Iqff2OStgTvycFeCopu5H2+kD Z4Qt845BWyZ8WPXJYNygD09DswqHng5XAVjGuz2Iqff2OStgTvycFeCopu5H2+kD
YW+TX7YDySuU2gzAI1BjyUBT303j5OSSeZ2S/UVMybSpb4OrghiXhVEdKbyIGoko YW+TX7YDySuU2gzAI1BjyUBT303j5OSSeZ2S/UVMybSpb4OrghiXhVEdKbyIGoko
V6zfSLQRguvzZyIn2ywsrmMz/J/wsnEBRKiOZNnLfJPZWtxp6empRzcFkmfQvbYM V6zfSLQRguvzZyIn2ywsrmMz/J/wsnEBRKiOZNnLfJPZWtxp6empRzcFkmfQvbYM
pWVOcIMEGO8zQE7iCUeSJJt4YEDceoUFnO7SbnexskUfGooGCSdmpXqc8BTI/oAc pWVOcIMEGO8zQE7iCUeSJJt4YEDceoUFnO7SbnexskUfGooGCSdmpXqc8BTI/oAc
v6Jn2b9IVGeXEl8qQ5HHRb9RdKGLvCsEJMWe0C0iJjSbNJbIyQZYm5Y2K82cN12E v6Jn2b9IVGeXEl8qQ5HHRb9RdKGLvCsEJMWe0C0iJjSbNJbIyQZYm5Y2K82cN12E
LTKLiFPzUdALiRbRdMb4/lOEZSwzpomIPjEMfsVWzTgEb+3V4E/X88/ZaYLQkU6x LTKLiFPzUdALiRbRdMb4/lOEZSwzpomIPjEMfsVWzTgEb+3V4E/X88/ZaYLQkU6x
xDlibYyKanrNk42+nsprRzNi8Nz8IHwtIR5MsvdM xDlibYyKanrNk42+nsprRzNi8Nz8IHwtIR5MsvdM
-----END PGP SIGNATURE----- -----END PGP SIGNATURE-----
Acknowledgments
Thanks to Daniel Kahn Gillmor, Justus Winter, Daniel Huigens,
Evangelos Karatsiolis, and early implementers of the document for
their reviews and feedback.
Contributors
Stephan Ehlen
BSI
Carl-Daniel Hailfinger
BSI
Andreas Huelsing
TU Eindhoven
Authors' Addresses Authors' Addresses
Stavros Kousidis Stavros Kousidis
BSI BSI
Germany Germany
Email: kousidis.ietf@gmail.com Email: kousidis.ietf@gmail.com
Johannes Roth Johannes Roth
MTG AG MTG AG
Germany Germany
 End of changes. 124 change blocks. 
696 lines changed or deleted 469 lines changed or added

This html diff was produced by rfcdiff 1.48.