]> NIST

USA quynh.dang@nist.gov

BSI

Germany stephan.ehlen@bsi.bund.de

BSI

Germany kousidis.ietf@gmail.com

MTG AG

Germany johannes.roth@mtg.de

MTG AG

Germany fstrenzke@cryptosource.de

sec Network Working Group Internet-Draft This document defines PQ/T ("post-quantum/traditional") composite schemes based on ML-KEM and ML-DSA combined with ECDH and ECDSA algorithms using the NIST and Brainpool domain parameters for the OpenPGP protocol , and as such extends . About This Document Status information for this document may be found at . Discussion of this document takes place on the WG Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document defines PQ/T composite schemes based on ML-KEM and ML-DSA combined with ECDH and ECDSA using the NIST and Brainpool domain parameters for the OpenPGP protocol . It is an extension of , which introduces post-quantum cryptography in OpenPGP using hybrid KEMs and digital signatures combining ML-KEM and ML-DSA with ECC algorithms based on the Edwards Curves defined in and . Due to their long-standing and wide deployment, there are well-tested, secure, and efficient implementations of ECDSA and ECDH with NIST-curves . The same applies to Brainpool curves which are recommended or required in certain regulatory domains, for instance in Germany . The purpose of this document is to support users who would like to or have to use such hybrid KEMs and/or signatures with OpenPGP.

Conventions used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. In wire format descriptions, the operator "||" is used to indicate concatenation of groups of octets.

Terminology for Multi-Algorithm Schemes The terminology in this document is oriented towards the definitions in . Specifically, the terms "multi-algorithm", "composite" and "non-composite" are used in correspondence with the definitions therein. The abbreviation "PQ" is used for post-quantum schemes. To denote the combination of post-quantum and traditional schemes, the abbreviation "PQ/T" is used.

Post-Quantum Cryptography This section describes the individual post-quantum cryptographic schemes. All schemes listed here are designed to provide security in the presence of a cryptographically relevant quantum computer.

ML-KEM ML-KEM is based on the hardness of solving the Learning with Errors problem in module lattices (MLWE). The scheme is believed to provide security against cryptanalytic attacks based on classical as well as quantum algorithms. This specification defines ML-KEM only in composite combination with ECDH encryption schemes in order to provide a pre-quantum security fallback.

ML-DSA ML-DSA is a signature scheme that, like ML-KEM, is based on the hardness of solving the Learning With Errors problem and a variant of the Short Integer Solution problem in module lattices (MLWE and SelfTargetMSIS). Accordingly, this specification only defines ML-DSA in composite combination with ECDSA signature schemes.

Elliptic Curve Cryptography The ECDH encryption is defined here as a KEM. All elliptic curves for the use in the composite combinations are taken from . For interoperability this extension offers ML-* in composite combinations with the NIST curves P-384, P-521 defined in and the Brainpool curves brainpoolP384r1, brainpoolP512r1 defined in .

Applicable Specifications for the use of PQC Algorithms in OpenPGP This document is to be understood as an extension of , which introduced PQC in OpenPGP, in that it defines further algorithm code points. All general specifications in that pertain to the ML-KEM and ML-DSA composite schemes or generally cryptographic schemes defined therein equally apply to the schemes specified in this document.

Preliminaries This section provides some preliminaries for the definitions in the subsequent sections.

Elliptic curves

SEC1 EC Point Wire Format Elliptic curve points of the generic prime curves are encoded using the SEC1 (uncompressed) format as the following octet string: where X and Y are coordinates of the elliptic curve point P = (X, Y), and each coordinate is encoded in the big-endian format and zero-padded to the adjusted underlying field size. The adjusted underlying field size is the underlying field size rounded up to the nearest 8-bit boundary, as noted in the "Field size" row in , , or . This encoding is compatible with the definition given in .

Measures to Ensure Secure Implementations In the following, measures are described that ensure secure implementations according to existing best practices and standards defining the operations of Elliptic Curve Cryptography. Even though the point at infinity, also referred to as the zero point, may 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 document. An implementation MAY signal an error if this condition is encountered. Furthermore, when performing the explicitly listed operations in it is REQUIRED to follow the specification and security advisory mandated by the respective elliptic curve specification. Specifically, this means that before performing the operations ECDH-KEM.Encaps() and ECDH-KEM.Decaps() defined in , an implementation MUST perform full public key validation, as defined in Section 5.6.2.3.3 of , on the received EC point that is input to the operation, that is, on the recipient's public key ecdhPublicKey in the case of encapsulation, and on the ephemeral public key ecdhCipherText in the case of decapsulation. That is, the implementation MUST verify that the point is not the point at infinity, that both of its coordinates are elements of the underlying field, and that the point satisfies the curve equation. If the validation fails, the operation MUST be aborted with an error.

Supported Public Key Algorithms This section specifies the composite ML-KEM + ECDH and ML-DSA + ECDSA schemes. All of these schemes are fully specified via their algorithm ID, that is, they are not parametrized.

Algorithm Specifications For encryption, the following composite KEM schemes are specified: KEM algorithm specifications

ID	Algorithm	Requirement	Definition
100	ML-KEM-768+ECDH-NIST-P-384	MAY
101	ML-KEM-1024+ECDH-NIST-P-521	MAY
102	ML-KEM-768+ECDH-brainpoolP384r1	MAY
103	ML-KEM-1024+ECDH-brainpoolP512r1	MAY

For signatures, the following composite signature schemes are specified: Signature algorithm specifications

ID	Algorithm	Requirement	Definition
104	ML-DSA-65+ECDSA-NIST-P-384	MAY
105	ML-DSA-87+ECDSA-NIST-P-521	MAY
106	ML-DSA-65+ECDSA-brainpoolP384r1	MAY
107	ML-DSA-87+ECDSA-brainpoolP512r1	MAY

An implementation MAY implement any of the listed algorithms.

Experimental Codepoints for Interop Testing [ Note: this section to be removed before publication ] The use of private/experimental codepoints during development are intended to be used in non-released software only, for experimentation and interop testing purposes only. An OpenPGP implementation MUST NOT produce a formal release using these experimental codepoints. This draft will not be sent to IANA without every listed algorithm having a non-experimental codepoint.

Algorithm Combinations

Composite KEMs The ML-KEM + ECDH public key encryption involves both the ML-KEM and an ECDH KEM in a non-separable manner. This is achieved via KEM combination, that is, both key encapsulations/decapsulations are performed in parallel, and the resulting key shares are fed into a key combiner to produce a single shared secret for message encryption. As explained in , the OpenPGP protocol inherently supports parallel encryption to different keys. Note that the confidentiality of a message is not post-quantum secure when encrypting to different keys unless all keys support PQ or PQ/T encryption schemes.

Composite Signatures The ML-DSA + ECDSA signature consists of independent ML-DSA and ECDSA signatures, and an implementation MUST successfully validate both signatures to state that the ML-DSA + ECDSA signature is valid.

Key Version Binding All PQ/T asymmetric algorithms defined in this document are to be used only in v6 (and newer) keys and certificates.

Composite KEM Schemes

Building Blocks

ECDH KEM In this section the encryption, decryption, and data formats for the ECDH component of the composite algorithms are defined. and describe the ECDH KEM parameters and artifact lengths. NIST curves parameters and artifact lengths

	NIST P-384	NIST P-521
Algorithm ID reference	100	101
Field size	48 octets	66 octets
ECDH KEM	ECDH-KEM	ECDH-KEM
ECDH public key	97 octets of SEC1-encoded public point	133 octets of SEC1-encoded public point
ECDH secret key	48 octets big-endian encoded secret scalar	66 octets big-endian encoded secret scalar
ECDH ephemeral	97 octets of SEC1-encoded ephemeral point	133 octets of SEC1-encoded ephemeral point
ECDH key share	48 octets	66 octets

Brainpool curves parameters and artifact lengths

	brainpoolP384r1	brainpoolP512r1
Algorithm ID reference	102	103
Field size	48 octets	64 octets
ECDH KEM	ECDH-KEM	ECDH-KEM
ECDH public key	97 octets of SEC1-encoded public point	129 octets of SEC1-encoded public point
ECDH secret key	48 octets big-endian encoded secret scalar	64 octets big-endian encoded secret scalar
ECDH ephemeral	97 octets of SEC1-encoded ephemeral point	129 octets of SEC1-encoded ephemeral point
ECDH key share	48 octets	64 octets

The SEC1 format for point encoding is defined in . The various procedures to perform the operations of an ECDH KEM are defined in the following subsections. Specifically, each of these subsections defines the instances of the following operations: and To instantiate ECDH-KEM, one must select a parameter set from or .

ECDH-KEM The operation ECDH-KEM.Encaps() is defined as follows:

1. Generate an ephemeral key pair {v, V=vG} as defined in Appendix A of where v is a random scalar with 0 < v < n, n being the base point order of the elliptic curve domain parameters
2. Compute the shared point S = vR, where R is the recipient's public key ecdhPublicKey, according to or
3. Extract the X coordinate from the SEC1 encoded point S = 04 || X || Y as defined in section
4. Set the output ecdhCipherText to the SEC1 encoding of V
5. Set the output ecdhKeyShare to X

The operation ECDH-KEM.Decaps() is defined as follows:

1. Compute the shared Point S as rV, where r is the ecdhSecretKey and V is the ecdhCipherText, according to or
2. Extract the X coordinate from the SEC1 encoded point S = 04 || X || Y as defined in section
3. Set the output ecdhKeyShare to X

For both of the above operations, elliptic curve point validation as specified in has to be realised.

ML-KEM ML-KEM features the following operations: and The above are the operations ML-KEM.Encaps and ML-KEM.Decaps defined in . Note that mlkemPublicKey is the encapsulation and mlkemSecretKey is the decapsulation key. ML-KEM has the parametrization with the corresponding artifact lengths in octets as given in . All artifacts are encoded as defined in . ML-KEM parameters and artifact lengths

	ML-KEM-768	ML-KEM-1024
Algorithm ID reference	100, 102	101, 103
Public (encapsulation) key	1184 octets	1568 octets
Secret (decapsulation) key	64 octets	64 octets
Ciphertext	1088 octets	1568 octets
Key share (shared secret key)	32 octets	32 octets

To instantiate ML-KEM, one must select a parameter set from the respective column of .

Composite Encryption Schemes with ML-KEM specifies the following ML-KEM + ECDH composite public key encryption schemes: ML-KEM + ECDH composite schemes

Algorithm ID reference	ML-KEM	ECDH-KEM curve
100	ML-KEM-768	NIST P-384
101	ML-KEM-1024	NIST P-521
102	ML-KEM-768	brainpoolP384r1
103	ML-KEM-1024	brainpoolP512r1

The ML-KEM + ECDH composite public key encryption schemes are built according to the following principal design:

• The ML-KEM encapsulation algorithm is invoked to create an ML-KEM ciphertext together with an ML-KEM symmetric key share.
• The encapsulation algorithm of an ECDH KEM is invoked to create an ECDH ciphertext together with an ECDH symmetric key share.
• A Key Encryption Key (KEK) is computed as the output of a key combiner that receives as input both of the above created symmetric key shares, the ECDH ciphertext, the ECDH public key, and the protocol binding information.
• The session key for content encryption, generated as specified in , is then wrapped as described in using AES-256 as algorithm and the KEK as key.
• The Public Key Encrypted Session Key (PKESK) packet's algorithm-specific parts are made up of the ML-KEM ciphertext, the ECDH ciphertext, and the wrapped session key.

Key Combiner For the composite KEM schemes defined in this document the procedure multiKeyCombine that is defined in MUST be used to compute the KEK that wraps a session key.

Key Generation Procedure The implementation MUST generate the ML-KEM and the ECDH component keys independently. ML-KEM key generation follows the specification in , and the artifacts are encoded as fixed-length octet strings whose sizes are listed in . ECDH key generation follows the specification in Appendix A of , and the artifacts are encoded as fixed-length octet strings whose sizes and format are listed in or .

Encryption Procedure The procedure to perform public key encryption with an ML-KEM + ECDH composite scheme is as follows:

1. Take the recipient's authenticated public key packet pkComposite and sessionKey as input
2. Parse the algorithm ID from pkComposite and set it as algId
3. Extract the ecdhPublicKey and mlkemPublicKey component from the algorithm specific data encoded in pkComposite with the format specified in .
4. Instantiate the ECDH-KEM and the ML-KEM depending on the algorithm ID according to
5. Compute (ecdhCipherText, ecdhKeyShare) = ECDH-KEM.Encaps(ecdhPublicKey)
6. Compute (mlkemCipherText, mlkemKeyShare) = ML-KEM.Encaps(mlkemPublicKey)
7. Compute KEK = multiKeyCombine(mlkemKeyShare, ecdhKeyShare, ecdhCipherText, ecdhPublicKey, algId) as defined in
8. Compute C = AESKeyWrap(KEK, sessionKey) with AES-256 as per that includes a 64 bit integrity check
9. Output the algorithm specific part of the PKESK as ecdhCipherText || mlkemCipherText || len(C, symAlgId) (|| symAlgId) || C, where both symAlgId and len(C, symAlgId) are single octet fields, symAlgId denotes the symmetric algorithm ID used and is present only for a v3 PKESK, and len(C, symAlgId) denotes the combined octet length of the fields specified as the arguments.

Decryption Procedure The procedure to perform public key decryption with an ML-KEM + ECDH composite scheme is as follows:

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 session key as encryptedKey
3. Check that the own and the extracted algorithm ID match
4. Parse the ecdhSecretKey and mlkemSecretKey from the algorithm- specific data of the own secret key, and the ecdhPublicKey from the algorithm-specific data of the own public key, encoded in the formats specified in .
5. Instantiate the ECDH-KEM and the ML-KEM depending on the algorithm ID according to
6. Parse ecdhCipherText, mlkemCipherText, and C from encryptedKey encoded as ecdhCipherText || mlkemCipherText || len(C, symAlgId) (|| symAlgId) || C as specified in , where symAlgId is present only in the case of a v3 PKESK.
7. Compute (ecdhKeyShare) = ECDH-KEM.Decaps(ecdhCipherText, ecdhSecretKey)
8. Compute (mlkemKeyShare) = ML-KEM.Decaps(mlkemCipherText, mlkemSecretKey)
9. Compute KEK = multiKeyCombine(mlkemKeyShare, ecdhKeyShare, ecdhCipherText, ecdhPublicKey, algId) as defined in
10. Compute sessionKey = AESKeyUnwrap(KEK, C) with AES-256 as per , aborting if the 64 bit integrity check fails
11. Output sessionKey

Packet Specifications

Public Key Encrypted Session Key Packets (Packet Type ID 1) The algorithm-specific fields consist of the output of the encryption procedure described in :

• A fixed-length octet string representing an ECDH ephemeral public key in the format associated with the curve as specified in .
• A fixed-length octet string of the ML-KEM ciphertext, whose length depends on the algorithm ID as specified in .
• A one-octet size of the following fields.
• Only in the case of a v3 PKESK packet: a one-octet symmetric algorithm identifier.
• The wrapped session key represented as an octet string.

Note that like in the case of the algorithms X25519 and X448 specified in , for the ML-KEM composite schemes, in the case of a v3 PKESK packet, the symmetric algorithm identifier is not encrypted. Instead, it is prepended to the wrapped session key in plaintext and its length is included in the preceding length field. In the case of v3 PKESK packets for ML-KEM composite schemes, the symmetric algorithm used MUST be AES-128, AES-192 or AES-256 (algorithm ID 7, 8 or 9). In the case of a v3 PKESK, a receiving implementation MUST check if the length of the unwrapped symmetric key matches the symmetric algorithm identifier, and abort if this is not the case. Implementations MUST NOT use the obsolete Symmetrically Encrypted Data packet (Packet Type ID 9) to encrypt data protected with the algorithms described in this document.

Key Material Packets The composite ML-KEM + ECDH schemes defined in this specification MUST be used only with v6 keys, as defined in , or newer versions defined by updates of that document.

Public Key Packets (Packet Type IDs 6 and 14) The algorithm-specific public key is this series of values:

• A fixed-length octet string representing an ECC public key, in the point format associated with the curve specified in .
• A fixed-length octet string containing the ML-KEM public key, whose length depends on the algorithm ID as specified in .

Secret Key Packets (Packet Type IDs 5 and 7) The algorithm-specific secret key is these two values:

• A fixed-length octet string of the encoded ECDH secret key, whose encoding and length depend on the algorithm ID as specified in .
• A fixed-length octet string containing the ML-KEM secret key in seed format, whose length is 64 octets (compare ). The seed format is defined in accordance with Section 3.3 of . Namely, the secret key is given by the concatenation of the values of d and z, generated in steps 1 and 2 of ML-KEM.KeyGen , each of a length of 32 octets. Upon parsing the secret key format, or before using the secret key, for the expansion of the key, the function ML-KEM.KeyGen_internal has to be invoked with the parsed values of d and z as input.

Composite Signature Schemes

Building Blocks

ECDSA-Based Signatures To sign and verify with ECDSA the following operations are defined: and Here, the operation ECDSA.Sign() is defined as the algorithm in Section "6.4.1 ECDSA Signature Generation Algorithm" of , however, excluding Step 1: H = Hash(M) in that algorithm specification, as in this specification the message digest H is a direct input to the operation ECDSA.Sign(). Equivalently, the operation ECDSA.Sign() can be understood as representing the algorithm under Section "4.2.1.1. Signature Algorithm" in , again with the difference that in this specification the message digest H_Tau(M) appearing in Step 5 of the algorithm specification is the direct input to the operation ECDSA.Sign() and thus the hash computation is not carried out. The same statement holds for the definition of the verification operation ECDSA.Verify(): it is given either through the algorithm defined in Section "6.4.2 ECDSA Signature Verification Algorithm" of omitting the message digest computation in Step 2 or by the algorithm in Section "4.2.1.2. Verification Algorithm" of omitting the message digest computation in Step 3. The public keys MUST be encoded in SEC1 format as defined in section . The secret key, as well as both values R and S of the signature MUST each be encoded as a big-endian integer in a fixed-length octet string of the specified size. The following table describes the ECDSA parameters and artifact lengths: ECDSA parameters and artifact lengths

	NIST P-384	NIST-P-521	brainpoolP384r1	brainpoolP512r1
Algorithm ID reference	104	105	106	107
Field size	48 octets	66 octets	48 octets	64 octets
Public key	97 octets	133 octets	97 octets	129 octets
Secret (Private) key	48 octets	66 octets	48 octets	64 octets
Signature value R	48 octets	66 octets	48 octets	64 octets
Signature value S	48 octets	66 octets	48 octets	64 octets

ML-DSA Signatures Throughout this specification ML-DSA refers to the default pure and hedged version of ML-DSA defined in . ML-DSA signature generation is performed using the default hedged version of the ML-DSA.Sign algorithm, as specified in , with an empty context string ctx. That is, to sign with ML-DSA the following operation is defined: ML-DSA signature verification is performed using the ML-DSA.Verify algorithm, as specified in , with an empty context string ctx. That is, to verify with ML-DSA the following operation is defined: ML-DSA has the parametrization with the corresponding artifact lengths in octets as given in . All artifacts are encoded as defined in . ML-DSA parameters and artifact lengths

	ML-DSA-65	ML-DSA-87
Algorithm ID reference	104, 106	105, 107
Public key	1952 octets	2592 octets
Secret (Private) key	32 octets	32 octets
Signature	3309 octets	4627 octets

Composite Signature Schemes with ML-DSA

Key Generation Procedure The implementation MUST generate the ML-DSA and the ECDSA component keys independently. ML-DSA key generation follows the specification in and the artifacts are encoded as fixed-length octet strings whose sizes are listed in . ECDSA key generation follows the specification in Appendix A of , and the artifacts are encoded as fixed-length octet strings whose sizes are listed in .

Signature Generation To sign a message M with ML-DSA + ECDSA the following sequence of operations has to be performed:

1. Generate dataDigest according to
2. Create the ECDSA signature over dataDigest with ECDSA.Sign() from
3. Create the ML-DSA signature over dataDigest with ML-DSA.Sign() from
4. Encode the ECDSA and ML-DSA signatures according to the packet structure given in

Signature Verification To verify an ML-DSA + ECDSA signature the following sequence of operations has to be performed:

1. Verify the ECDSA signature with ECDSA.Verify() from
2. Verify the ML-DSA signature with ML-DSA.Verify() from

As specified in an implementation MUST validate both signatures, that is, ECDSA and ML-DSA, successfully to state that a composite ML-DSA + ECDSA signature is valid.

Packet Specifications

Signature Packet (Packet Type ID 2) The composite ML-DSA + ECDSA schemes MUST be used only with v6 signatures, as defined in , or newer versions defined by updates of that document. The algorithm-specific v6 signature parameters for ML-DSA + ECDSA signatures consist of:

• A fixed-length octet string of the big-endian encoded ECDSA value R, whose length depends on the algorithm ID as specified in .
• A fixed-length octet string of the big-endian encoded ECDSA value S, whose length depends on the algorithm ID as specified in .
• A fixed-length octet string of the ML-DSA signature value, whose length depends on the algorithm ID as specified in .

A composite ML-DSA + ECDSA signature MUST use a hash algorithm with a digest size of at least 256 bits for the computation of the message digest. A verifying implementation MUST reject any composite ML-DSA + ECDSA signature that uses a hash algorithm with a smaller digest size.

Key Material Packets The composite ML-DSA + ECDSA schemes MUST be used only with v6 keys, as defined in , or newer versions defined by updates of that document.

Public Key Packets (Packet Type IDs 6 and 14) The algorithm-specific public key for ML-DSA + ECDSA keys is this series of values:

• A fixed-length octet string representing the ECDSA public key in SEC1 format, as specified in section , whose length depends on the algorithm ID as specified in .
• A fixed-length octet string containing the ML-DSA public key, whose length depends on the algorithm ID as specified in .

Secret Key Packets (Packet Type IDs 5 and 7) The algorithm-specific secret key for ML-DSA + ECDSA keys is this series of values:

• A fixed-length octet string representing the ECDSA secret key as a big-endian encoded integer, whose length depends on the algorithm ID as specified in .
• A fixed-length octet string containing the ML-DSA secret key in seed format, whose length is 32 octets (compare ). The seed format is defined in accordance with Section 3.6.3 of . Namely, the secret key is given by the value xi generated in step 1 of ML-DSA.KeyGen . Upon parsing the secret key format, or before using the secret key, for the expansion of the key, the function ML-DSA.KeyGen_internal has to be invoked with the parsed value of xi as input.

Security Considerations The following security considerations given in equally apply to this document:

• the security aspects of composite signatures (),
• the arguments for the security features of the KEM combiner given in , as also the NIST and Brainpool curves represent nominal groups according to ,
• the considerations regarding domain separation and context binding for the KEM combiner (),
• the use of the hedged variant of ML-DSA (),
• the minimum digest size for PQ/T signatures (),
• the use of symmetric encryption in SEIPD packets (),
• the key generation for composite schemes (),
• and random number generation and seeding ().

When implementing or using any of the algorithms defined in this specification, the above referenced security considerations should be noted.

Elliptic Curve Point Validation In contrast to the Montgomery and Edwards curves used for the composite schemes defined in , the NIST and Brainpool curves used in this document are curves in short Weierstrass form. For these curves, performing a scalar multiplication of a secret scalar with an attacker-controlled point that does not lie on the curve can enable invalid-curve attacks, which can lead to the recovery of the ECDH secret key. To prevent these attacks, the procedures described in require implementations to perform full public key validation according to Section 5.6.2.3.3 of on all EC points that are input to the ECDH-KEM operations.

IANA Considerations IANA is requested to add the algorithm IDs defined in to the existing registry OpenPGP Public Key Algorithms maintained at . The field specifications enclosed in brackets for the ML-KEM + ECDH composite algorithms denote fields that are only conditionally contained in the data structure. IANA updates for registry 'OpenPGP Public Key Algorithms'

ID	Algorithm	Public Key Format	Secret Key Format	Signature Format	PKESK Format	Reference
TBD	ML-KEM-768+ECDH-NIST-P-384	97 octets ECDH public key (), 1184 octets ML-KEM-768 public key ()	48 octets ECDH secret key (), 64 octets ML-KEM-768 secret key ()	N/A	97 octets ECDH ciphertext, 1088 octets ML-KEM-768 ciphertext, 1 octet remaining length, [1 octet algorithm ID in case of v3 PKESK,] n octets wrapped session key ()
TBD	ML-KEM-1024+ECDH-NIST-P-521	133 octets ECDH public key (), 1568 octets ML-KEM-1024 public key ()	66 octets ECDH secret key (), 64 octets ML-KEM-1024 secret key ()	N/A	133 octets ECDH ciphertext, 1568 octets ML-KEM-1024 ciphertext, 1 octet remaining length, [1 octet algorithm ID in case of v3 PKESK,] n octets wrapped session key ()
TBD	ML-KEM-768+ECDH-brainpoolP384r1	97 octets ECDH public key (), 1184 octets ML-KEM-768 public key ()	48 octets ECDH secret key (), 64 octets ML-KEM-768 secret key ()	N/A	97 octets ECDH ciphertext, 1088 octets ML-KEM-768 ciphertext, 1 octet remaining length, [1 octet algorithm ID in case of v3 PKESK,] n octets wrapped session key ()
TBD	ML-KEM-1024+ECDH-brainpoolP512r1	129 octets ECDH public key (), 1568 octets ML-KEM-1024 public key ()	64 octets ECDH secret key (), 64 octets ML-KEM-1024 secret key ()	N/A	129 octets ECDH ciphertext, 1568 octets ML-KEM-1024 ciphertext, 1 octet remaining length, [1 octet algorithm ID in case of v3 PKESK,] n octets wrapped session key ()
TBD	ML-DSA-65+ECDSA-NIST-P-384	97 octets ECDSA public key (), 1952 octets ML-DSA-65 public key ()	48 octets ECDSA secret key (), 32 octets ML-DSA-65 secret key ()	96 octets ECDSA signature , 3309 octets ML-DSA-65 signature ()	N/A
TBD	ML-DSA-87+ECDSA-NIST-P-521	133 octets ECDSA public key (), 2592 octets ML-DSA-87 public key ()	66 octets ECDSA secret key (), 32 octets ML-DSA-87 secret key ()	132 octets ECDSA signature , 4627 octets ML-DSA-87 signature ()	N/A
TBD	ML-DSA-65+ECDSA-brainpoolP384r1	97 octets ECDSA public key (), 1952 octets ML-DSA-65 public key ()	48 octets ECDSA secret key (), 32 octets ML-DSA-65 secret key ()	96 octets ECDSA signature , 3309 octets ML-DSA-65 signature ()	N/A
TBD	ML-DSA-87+ECDSA-brainpoolP512r1	129 octets ECDSA public key (), 2592 octets ML-DSA-87 public key ()	64 octets ECDSA secret key (), 32 octets ML-DSA-87 secret key ()	128 octets ECDSA signature , 4627 octets ML-DSA-87 signature ()	N/A

IANA is asked to add the following note to this registry:

• The field specifications enclosed in square brackets for PKESK Format represent fields that may or may not be present, depending on the PKESK version.

Changelog This section gives the history of changes in the respective document versions. The order is newest-first.

draft-ietf-openpgp-nist-bp-comp-04

• Added the requirement to perform full public key validation on received EC points in the ECDH-KEM operations, and a corresponding security consideration regarding invalid-curve attacks.
• Fixed errors in the IANA table: ECDH secret key length for P-521 (66 instead of 64 octets), ML-KEM-1024 public key labels, and a wrong table reference for the ECDH secret key format.
• Corrected the description of the placement of the symmetric algorithm identifier in v3 PKESK packets to match the wire format and .
• Fixed the mislabeled reference to FIPS 186-5 (previously labeled as SP 800-186) and cite FIPS 186-5 Appendix A for EC key generation.
• Decryption procedure: clarified that ecdhPublicKey is taken from the public key part of the own secret key packet.
• Removed a stale editor's note above the IANA table.
• Update reference I-D.draft-ietf-openpgp-pqc to RFC 9980
• Change email address of one author.

draft-ietf-openpgp-nist-bp-comp-03

• Fix: Display test vector public keys (instead of secret keys).
• Align with (relevant) editorial changes from IESG review of .

draft-ietf-openpgp-nist-bp-comp-02

• Updated algorithm selection and assigned experimental code points 100-107.
• Added test vectors.

draft-ietf-openpgp-nist-bp-comp-01

• Editorial alignment to .

draft-ietf-openpgp-nist-bp-comp-00

• Changed draft title.

draft-ehlen-openpgp-nist-bp-comp-02

• Completed the IANA table.
• Added "Security Considerations" section.
• Alignment of various technical details to .
• Various editorial alignments to .

draft-ehlen-openpgp-nist-bp-comp-01

• Replaced the explicit description of the KEM combiner with a reference to .

Contributors

References Normative References This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581 ("The Camellia Cipher in OpenPGP"), and 6637 ("Elliptic Curve Cryptography (ECC) in OpenPGP"). This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. The purpose of this document is to make the AES Key Wrap algorithm conveniently available to the Internet community. The United States of America has adopted AES as the new encryption standard. The AES Key Wrap algorithm will probably be adopted by the USA for encryption of AES keys. The authors took most of the text in this document from the draft AES Key Wrap posted by NIST. This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines a post-quantum public key algorithm extension for the OpenPGP protocol, extending RFC 9580. Given the generally assumed threat of a cryptographically relevant quantum computer, this extension provides a basis for long-term secure OpenPGP signatures and ciphertexts. Specifically, it defines composite public key encryption based on ML-KEM (formerly CRYSTALS-Kyber), composite public key signatures based on ML-DSA (formerly CRYSTALS-Dilithium), both in combination with Elliptic Curve Cryptography (ECC), and SLH-DSA (formerly SPHINCS+) as a standalone public key signature scheme. Standards for Efficient Cryptography Group National Institute of Standards and Technology National Institute of Standards and Technology IANA n.d. Information Technology Laboratory, National Institute of Standards and Technology In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Federal Office for Information Security, Germany One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations.

Test Vectors

Sample ML-DSA-65+ECDSA-NIST-P-384 with ML-KEM-768+ECDH-NIST-P-384 Data

Transferable Secret Key Here is a Transferable Secret Key consisting of:

• A v6 ML-DSA-65+ECDSA-NIST-P-384 Private Key packet
• A v6 direct key self-signature
• A User ID packet
• A v6 positive certification self-signature
• A v6 ML-KEM-768+ECDH-NIST-P-384 Private Subkey packet
• A v6 subkey binding signature

The primary key has the fingerprint a3f3ea658b8324df76694581f4f6fede3e15bb0b67c7520255d2f7868208d756. The subkey has the fingerprint 16addcbd549eb8c4153c9626b6aa4dac17adeac4f79c54dfcbe4aabaa28aba1b.

Transferable Public Key Here is the corresponding Transferable Public Key for consisting of:

• A v6 ML-DSA-65+ECDSA-NIST-P-384 Public Key packet
• A v6 direct key self-signature
• A User ID packet
• A v6 positive certification self-signature
• A v6 ML-KEM-768+ECDH-NIST-P-384 Public Subkey packet
• A v6 subkey binding signature

Encrypted and Signed Message Here is a signed message "Testing\n" encrypted to the certificate and signed by the secret key :

• A v6 PKESK
• A v2 SEIPD

The hex-encoded mlkemKeyShare input to multiKeyCombine is 26da669cc569a460708f96b0e4132488c2f990b931a7fa4e02625f3f4293e7b5. The hex-encoded ecdhKeyShare input to multiKeyCombine is b1564c7701bdf47ac5825908aac109cd4fafa0c528beefe73be02248dff8f2665e8e01d38fd17424af32c8acaabdfe17. The hex-encoded output of multiKeyCombine is ea93bb3825128c37f318018d74867cdb451317ae3fa6b64da0eca7931cd8bd7c. The hex-encoded session key is 0c251def2936896735f8903bf6382d822e6aa3791104b1a2da02e142a10dc38f.

Sample ML-DSA-87+ECDSA-NIST-P-521 with ML-KEM-1024+ECDH-NIST-P-521 Data

Transferable Secret Key Here is a Transferable Secret Key consisting of:

• A v6 ML-DSA-87+ECDSA-NIST-P-521 Private Key packet
• A v6 direct key self-signature
• A User ID packet
• A v6 positive certification self-signature
• A v6 ML-KEM-1024+ECDH-NIST-P-521 Private Subkey packet
• A v6 subkey binding signature

The primary key has the fingerprint e3674a3dcbfc35fcc24b1cd7f55213a3866d17b6081c3ad5933af3d78e8c8bce. The subkey has the fingerprint c22c679c40289df8111fda26f1cc8eca6c08dcbc8e20ceaac7e6b7ddd3b040bb.

Transferable Public Key Here is the corresponding Transferable Public Key for consisting of:

• A v6 ML-DSA-87+ECDSA-NIST-P-521 Public Key packet
• A v6 direct key self-signature
• A User ID packet
• A v6 positive certification self-signature
• A v6 ML-KEM-1024+ECDH-NIST-P-521 Public Subkey packet
• A v6 subkey binding signature

Encrypted and Signed Message Here is a signed message "Testing\n" encrypted to the certificate and signed by the secret key :

• A v6 PKESK
• A v2 SEIPD

The hex-encoded mlkemKeyShare input to multiKeyCombine is cd8a9216c981c151843d48ce17a30cb69f01373c35032d313ce34244cbaa0e35. The hex-encoded ecdhKeyShare input to multiKeyCombine is 016ca7330ea0a216376803717001269aeb8a94083b20bb3a1a709f8aeb322219759d9ff7872bab303e357f78507d423f59d3e2206e67537aba75280ca7937e250b5b. The hex-encoded output of multiKeyCombine is 6c514547454fbb8ff7308c80d79f59d1cde7d99a2fe2a2a1ac4e31114906b186. The hex-encoded session key is 371de99d254c0a0d4ee2c1b63d2a4956bbfe84cdafa4b264dcc59b80ece9d8f4.

Sample ML-DSA-65+ECDSA-brainpoolP384r1 with ML-KEM-768+ECDH-brainpoolP384r1 Data

Transferable Secret Key Here is a Transferable Secret Key consisting of:

• A v6 ML-DSA-65+ECDSA-brainpoolP384r1 Private Key packet
• A v6 direct key self-signature
• A User ID packet
• A v6 positive certification self-signature
• A v6 ML-KEM-768+ECDH-brainpoolP384r1 Private Subkey packet
• A v6 subkey binding signature

The primary key has the fingerprint 6a498c10ff01ddfb1c28d0af05afe75d4c0e625d73fe8ab3cca227bd162d57b7. The subkey has the fingerprint 408b08b20df93c6abdefb25d87a642766e6455caac621e8ca8204234de7bdedb.

Transferable Public Key Here is the corresponding Transferable Public Key for consisting of:

• A v6 ML-DSA-65+ECDSA-brainpoolP384r1 Public Key packet
• A v6 direct key self-signature
• A User ID packet
• A v6 positive certification self-signature
• A v6 ML-KEM-768+ECDH-brainpoolP384r1 Public Subkey packet
• A v6 subkey binding signature

Encrypted and Signed Message Here is a signed message "Testing\n" encrypted to the certificate and signed by the secret key :

• A v6 PKESK
• A v2 SEIPD

The hex-encoded mlkemKeyShare input to multiKeyCombine is 1eaa02a4cd82d01573d84c6e1326c19fe8d3cc6bca297e6525a7d84faff68cdf. The hex-encoded ecdhKeyShare input to multiKeyCombine is 0521a1adda540cc7b8589dc9cbe360d51139b3b1fc58f6b4a452baa2ec16022027b3495c04c4abb34e8bbd603d0ebeb7. The hex-encoded output of multiKeyCombine is ed4010d69f98dc64db6df1d9d59331708057b8027ea0336c03bad6ea3990b25a. The hex-encoded session key is b89c0629753f9e849a2bb176ba564fb7c674aecbe1f9c1d7f71001533871c20b.

Sample ML-DSA-87+ECDSA-brainpoolP512r1 with ML-KEM-1024+ECDH-brainpoolP512r1 Data

Transferable Secret Key Here is a Transferable Secret Key consisting of:

• A v6 ML-DSA-87+ECDSA-brainpoolP512r1 Private Key packet
• A v6 direct key self-signature
• A User ID packet
• A v6 positive certification self-signature
• A v6 ML-KEM-1024+ECDH-brainpoolP512r1 Private Subkey packet
• A v6 subkey binding signature

The primary key has the fingerprint b89e98c38b82bf6f859e7d259bc4d4526c7e6f3448a0b82d0dbe580e3278dba3. The subkey has the fingerprint 033fa728eb4a55a4d59a0496e51c90b67f70846de0ed3cdfb8f28124ec90d3fd.

Transferable Public Key Here is the corresponding Transferable Public Key for consisting of:

• A v6 ML-DSA-87+ECDSA-brainpoolP512r1 Public Key packet
• A v6 direct key self-signature
• A User ID packet
• A v6 positive certification self-signature
• A v6 ML-KEM-1024+ECDH-brainpoolP512r1 Public Subkey packet
• A v6 subkey binding signature

Encrypted and Signed Message Here is a signed message "Testing\n" encrypted to the certificate and signed by the secret key :

• A v6 PKESK
• A v2 SEIPD

The hex-encoded mlkemKeyShare input to multiKeyCombine is 66c0163a0f68f7b783b58cae6feeb4d2d6ad9b99cd2a7ac311fb78fdc42055c8. The hex-encoded ecdhKeyShare input to multiKeyCombine is 83662068efed595bbf0f3857bf2d31b4b1c85c1252803761758979819cbb060b0576cef35b3784913bf5a6fed92641bf0fd726f0dac4b137a7830a23e6adc070. The hex-encoded output of multiKeyCombine is ee6aa72fb27d4a5b6399761610ea0b52aadc391ead369656e3f5d136752d0bb9. The hex-encoded session key is 3fed681f8c216acbf665591f8b4618b455f8652c31f329664127a26b7677263e.

Acknowledgments