RFC 9980: Post-Quantum Cryptography in OpenPGP | RFC Editor

NIST

43 min read Original article ↗

Abstract

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.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

1. Introduction

The OpenPGP protocol [] supports various traditional public key algorithms based on the factoring or discrete logarithm problem. As the security of algorithms based on these mathematical problems is endangered by the advent of quantum computers, there is a need to extend OpenPGP with algorithms that remain secure in the presence of a Cryptographically Relevant Quantum Computer (CRQC), i.e., a quantum computer with sufficient capacity to break traditional public key cryptography.

Such cryptographic algorithms are referred to as "Post-Quantum Cryptography" (or "PQC"). The algorithms defined in this extension were chosen for standardization by the US National Institute of Standards and Technology (NIST) in mid-2022 [NISTIR-8413] as the result of the NIST Post-Quantum Cryptography Standardization process initiated in 2016 [NIST-PQC]. ML-KEM [FIPS-203] was selected as a Key Encapsulation Mechanism (KEM). A KEM is a modern building block for public key encryption. ML-DSA [FIPS-204] and SLH-DSA [FIPS-205] were selected as signature schemes.

For the ML-KEM and ML-DSA schemes, this document follows the conservative strategy to deploy post-quantum in combination with traditional schemes such that the security is retained even if all schemes but one in the combination are broken. Such combinations are referred to as "multi-algorithm" or "post-quantum/traditional" (or "PQ/T") hybrid algorithms. In contrast, the stateless hash-based signature scheme SLH-DSA is considered to be sufficiently well understood with respect to its security assumptions in order to be used standalone. To this end, this document specifies the following new set: SLH-DSA standalone and the two ML-* as composite with KEM based on ECC and digital signature schemes. Here, the term "composite" indicates that any data structure or algorithm pertaining to the combination of the two components appears as a single data structure or algorithm from the protocol perspective.

This document extends [] by adding KEM and signature algorithms specified in Sections 4, 5, and 6 and specifies the conventions for interoperability between compliant OpenPGP implementations.

1.1. 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.

1.1.1. Terminology for Multi-Algorithm Schemes

The terminology in this document is oriented towards the definitions in []. Specifically, the terms "multi-algorithm", "composite", "non-composite", and "traditional" 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. The short form "PQ(/T)" stands for PQ or PQ/T.

1.2. 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 CRQC. However, the mathematical problems on which the two ML-* schemes and SLH-DSA are based are fundamentally different, and, accordingly, the level of trust commonly placed in them as well as their performance characteristics vary.

1.2.1. ML-KEM

ML-KEM [FIPS-203] is based on the hardness of solving the Module Learning with Errors (MLWE) problem. 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 Elliptic Curve Diffie-Hellman (ECDH) encryption schemes in order to provide a pre-quantum security fallback.

1.2.2. ML-DSA

ML-DSA [FIPS-204] is a signature scheme that, like ML-KEM, is based on the hardness of solving the MLWE 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 Edwards-Curve Digital Signature Algorithm (EdDSA) signature schemes.

1.2.3. SLH-DSA

SLH-DSA [FIPS-205] is a stateless hash-based signature scheme. Its security relies on the hardness of finding preimages for cryptographic hash functions. This feature is generally considered to be a high security guarantee. Therefore, this specification defines SLH-DSA as a standalone signature scheme.

In deployments, the performance characteristics of SLH-DSA should be taken into account. The performance characteristics of this scheme are discussed in Section 10.1.

1.3. Elliptic Curve Cryptography

ECDH encryption is defined here as a KEM via X25519 and X448, which are defined in []. EdDSA as defined in [] is used as the elliptic curve-based digital signature scheme.

1.4. Standalone and Multi-Algorithm Schemes

This section provides a categorization of the new algorithms and their combinations.

1.4.1. Standalone and Composite Multi-Algorithm Schemes

This specification introduces new cryptographic schemes, which can be categorized as follows:

  • PQ/T multi-algorithm public key encryption, namely a composite combination of ML-KEM with ECDH,

  • PQ/T multi-algorithm digital signature, namely composite combinations of ML-DSA with EdDSA, and

  • PQ digital signature, namely SLH-DSA as a standalone cryptographic algorithm.

For each of the composite schemes, this specification mandates that the consuming party successfully perform the cryptographic algorithms for each of the component schemes used in a cryptographic message, for the message to be deciphered and considered as valid. This means that all component signatures must be verified successfully to achieve a successful verification of the composite signature. In the case of the composite public key decryption, each of the component KEM decapsulation operations must succeed.

1.4.2. Non-Composite Algorithm Combinations

As the OpenPGP protocol [] allows for multiple signatures to be applied to a single message, it is also possible to realize non-composite combinations of signatures. Furthermore, multiple OpenPGP signatures may be combined on the application layer. These latter two cases realize non-composite combinations of signatures. Section 3.3 specifies how implementations should handle the verification of such combinations of signatures.

Furthermore, the OpenPGP protocol also allows parallel encryption to different keys by using multiple Public Key Encrypted Session Key (PKESK) packets, thus realizing non-composite multi-algorithm public key encryption.

2. Supported Public Key Algorithms

This section specifies the composite ML-KEM + ECDH and ML-DSA + EdDSA schemes as well as the standalone SLH-DSA signature scheme. All of these schemes are fully specified via their algorithm ID, that is, they are not parameterized.

2.1. Algorithm Specifications

For signatures, the following (composite) signature schemes are specified:

For encryption, the following composite KEM schemes are specified:

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-1024+X448, but it may omit them if targeting a highly constrained environment. An implementation MAY implement any of the SLH-DSA algorithms.

The specified algorithm IDs offer two security levels for each scheme, for a trade-off between security and performance. The SLH-DSA algorithms offer an additional performance trade-off between signature generation time ("128f" is faster) and signature size ("128s" is smaller) at the lower of the two SLH-DSA security levels. The larger parameter sets of ML-DSA and ML-KEM (algorithm IDs 31 and 36) are recommended to support interoperability, but they are not required for compliance. Implementations targeting highly constrained environments may omit these larger variants.

For SLH-DSA-SHAKE-256, only the "small" variant is offered to contain signature size. See also Section 10.1 for further considerations about parameter choices.

3. Algorithm Combinations

3.1. Composite KEMs

The ML-KEM + ECDH public key encryption involves both the ML-KEM and an ECDH KEM in an a priori inseparable 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 Section 1.4.2, 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(/T) encryption schemes.

3.2. Composite Signatures

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

3.3. Multiple Signatures

The OpenPGP message format allows multiple signatures of a message, that is, the attachment of multiple signature packets.

An implementation MAY sign a message with a traditional key and a PQ(/T) key from the same sender. This ensures backwards compatibility due to Section 5.2.5 of [], since a legacy implementation without PQ(/T) support can fall back on the traditional signature.

Newer implementations with PQ(/T) support MAY ignore the traditional signature(s) during validation.

Implementations SHOULD consider the message correctly signed if at least one of the non-ignored signatures validates successfully. This is consistent with Section 5.2.5 of [].

3.4. ECC Requirements

Even though the zero point, also called the point at infinity, 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 Sections 4.1.1.1 or 4.1.1.2, it is REQUIRED to follow the specification and security advisory mandated from the respective elliptic curve specification [].

3.5. Key Version Binding

All PQ(/T) asymmetric algorithms are to be used only in v6 (and newer) keys and certificates, with the single exception of ML-KEM-768+X25519 (algorithm ID 35), which is also allowed in v4 encryption-capable subkeys.

4. Composite KEM Schemes

4.1. Building Blocks

4.1.1. ECDH KEM

In this section, the encryption, decryption, and data formats for the ECDH component of the composite algorithms are defined.

Table 3 describes the ECDH KEM parameters and artifact lengths. The artifacts in Table 3 follow the encodings described 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 Table 3.

4.1.1.1. X25519-KEM

The encapsulation and decapsulation operations of X25519-KEM are described using the function X25519() and encodings defined in []. The ecdhSecretKey is denoted as r and the ecdhPublicKey as R; they are subject to the equation R = X25519(r, U(P)). Here, U(P) denotes the u-coordinate of the base point of Curve25519.

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

  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 octets

  2. Compute the shared coordinate X = X25519(v, R) where R is the recipient's public key ecdhPublicKey

  3. Set the output ecdhCipherText to V

  4. Set the output ecdhKeyShare to X

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

  1. Compute the shared coordinate X = X25519(r, V), where r is the ecdhSecretKey and V is the ecdhCipherText

  2. Set the output ecdhKeyShare to X

4.1.1.2. X448-KEM

The encapsulation and decapsulation operations of X448-KEM are described using the function X448() and encodings defined in []. The ecdhSecretKey is denoted as r and the ecdhPublicKey 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.

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

  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

  2. Compute the shared coordinate X = X448(v, R) where R is the recipient's public key ecdhPublicKey

  3. Set the output ecdhCipherText to V

  4. Set the output ecdhKeyShare to X

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

  1. Compute the shared coordinate X = X448(r, V), where r is the ecdhSecretKey and V is the ecdhCipherText

  2. Set the output ecdhKeyShare to X

4.1.2. ML-KEM

ML-KEM features the following operations:

and

The above are the operations ML-KEM.Encaps and ML-KEM.Decaps defined in [FIPS-203]. Note that mlkemPublicKey is the encapsulation and mlkemSecretKey is the decapsulation key.

ML-KEM has the parameterization with the corresponding artifact lengths in octets as given in Table 4. All artifacts are encoded as defined in [FIPS-203].

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

4.2. Composite Encryption Schemes with ML-KEM

Table 2 specifies the following ML-KEM + ECDH composite public key encryption schemes:

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, namely X25519-KEM or X448-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 the algorithm and the KEK as the key.

  • The PKESK packet's algorithm-specific parts are made up of the ML-KEM ciphertext, the ECDH ciphertext, and the wrapped session key.

4.2.1. Key Combiner

For the composite KEM schemes defined in Table 2, the following procedure MUST be used to compute the KEK that wraps a session key. The construction is a key derivation function compliant with the QSF/X-Wing construction in [BCD_24], the generalization of which is analyzed in [CHHKM]. It is given by the following algorithm, which computes the KEK that is used to wrap (that is, encrypt) the session key.

The value domSep is a constant set to the UTF-8 encoding of the string "OpenPGPCompositeKDFv1", that is:

Here, len(domSep) is the single octet with the value equal to the octet-length of domSep, that is, decimal 21.

4.2.2. Key Generation Procedure

The implementation MUST generate the ML-KEM and the ECDH component keys independently. ML-KEM key generation follows the specification 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 follows the specification in [], and the artifacts are encoded as fixed-length octet strings whose sizes are listed in Table 3.

4.2.3. 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 components from the algorithm-specific data encoded in pkComposite with the format specified in Section 4.3.2

  4. Instantiate the ECDH-KEM and the ML-KEM depending on the algorithm ID according to Table 5

  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 Section 4.2.1

  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.

4.2.4. 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 encoded in the format specified in Section 4.3.2

  5. Instantiate the ECDH-KEM and the ML-KEM depending on the algorithm ID according to Table 5

  6. Parse ecdhCipherText, mlkemCipherText, and C from encryptedKey encoded as ecdhCipherText || mlkemCipherText || len(C, symAlgId) (|| symAlgId) || C as specified in Section 4.3.1, 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 Section 4.2.1

  10. Compute sessionKey = AESKeyUnwrap(KEK, C) with AES-256 as per [], aborting if the 64-bit integrity check fails

  11. Output sessionKey

4.3. Packet Specifications

4.3.1. Public Key Encrypted Session Key Packets (Packet Type ID 1)

The algorithm-specific fields consist of the output of the encryption procedure described in Section 4.2.3:

  • A fixed-length octet string representing an ECDH ephemeral public key in the format associated with the curve as specified in Section 4.1.1.

  • A fixed-length octet string of the ML-KEM ciphertext whose length depends on the algorithm ID as specified in Table 4.

  • 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, for the ML-KEM composite schemes, in the case of a v3 PKESK packet, the symmetric algorithm identifier is not encrypted. This follows the construction of X25519 and X448 specified in []. 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 IDs 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 ID 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.

4.3.2. Key Material Packets

The composite ML-KEM-768 + X25519 (algorithm ID 35) MUST be used only with v4 or v6 keys, as defined in [], or newer versions defined by updates of that document.

The composite ML-KEM-1024 + X448 (algorithm ID 36) MUST be used only with v6 keys, as defined in [], or newer versions defined by updates of that document.

4.3.2.1. 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 Section 4.1.1.

  • A fixed-length octet string containing the ML-KEM public key whose length depends on the algorithm ID as specified in Table 4.

4.3.2.2. Secret Key Packets (Packet Type IDs 5 and 7)

The algorithm-specific secret key is comprised of 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 Section 4.1.1.

  • 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 is defined in accordance with Section 3.3 of [FIPS-203]. 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 [FIPS-203], 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 [FIPS-203] has to be invoked with the parsed values of d and z as input.

5. Composite Signature Schemes

5.1. Building Blocks

5.1.1. EdDSA-Based Signatures

Throughout this specification, "EdDSA" refers to the PureEdDSA variant defined in []. The context is always empty.

To sign and verify with EdDSA, the following operations are defined:

and

The public and secret key, as well as the signature, MUST be encoded according to [] as fixed-length octet strings. The following table describes the EdDSA parameters and artifact lengths:

5.1.2. ML-DSA Signatures

Throughout this specification, "ML-DSA" refers to the default pure and hedged version of ML-DSA defined in [FIPS-204].

ML-DSA signature generation is performed using the default hedged 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 following operation is defined:

ML-DSA signature verification is performed using the ML-DSA.Verify algorithm, as specified in [FIPS-204], with an empty context string ctx. That is, to verify with ML-DSA, the following operation is defined:

ML-DSA has the parameterization with the corresponding artifact lengths in octets as given in Table 7. All artifacts are encoded as defined in [FIPS-204].

5.2. Composite Signature Schemes with ML-DSA

5.2.1. Key Generation Procedure

The implementation MUST generate the ML-DSA and the EdDSA component keys independently. ML-DSA key generation follows the specification in [FIPS-204], and the artifacts are encoded as fixed-length octet strings whose sizes are listed in Section 5.1.2. EdDSA key generation follows the specification in [], and the artifacts are encoded as fixed-length octet strings whose sizes are listed in Section 5.1.1.

5.2.2. Signature Generation

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

  1. Generate dataDigest according to Section 5.2.4 of []

  2. Create the EdDSA signature over dataDigest with EdDSA.Sign() from Section 5.1.1

  3. Create the ML-DSA signature over dataDigest with ML-DSA.Sign() from Section 5.1.2

  4. Encode the EdDSA and ML-DSA signatures according to the packet structure given in Section 5.3.1

5.2.3. Signature Verification

To verify an ML-DSA + EdDSA signature, the following sequence of operations has to be performed:

  1. Verify the EdDSA signature with EdDSA.Verify() from Section 5.1.1

  2. Verify the ML-DSA signature with ML-DSA.Verify() from Section 5.1.2

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

5.3. Packet Specifications

5.3.1. Signature Packet (Packet Type ID 2)

The composite ML-DSA + EdDSA 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 + EdDSA signatures consist of:

  • A fixed-length octet string representing the EdDSA signature whose length depends on the algorithm ID as specified in Table 6.

  • A fixed-length octet string of the ML-DSA signature value whose length depends on the algorithm ID as specified in Table 7.

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. A verifying implementation MUST reject any composite ML-DSA + EdDSA signature that uses a hash algorithm with a smaller digest size.

5.3.2. Key Material Packets

The composite ML-DSA + EdDSA schemes MUST be used only with v6 keys, as defined in [], or newer versions defined by updates of that document.

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 series of values:

  • A fixed-length octet string representing the EdDSA public key whose length depends on the algorithm ID as specified in Table 6.

  • A fixed-length octet string containing the ML-DSA public key whose length depends on the algorithm ID as specified in Table 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 series of values:

  • A fixed-length octet string representing the EdDSA secret key whose length depends on the algorithm ID as specified in Table 6.

  • 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 is defined in accordance with Section 3.6.3 of [FIPS-204]. Namely, the secret key is given by the value xi generated in step 1 of ML-DSA.KeyGen [FIPS-204]. Upon parsing the secret key format, or before using the secret key, for the expansion of the key, the function ML-DSA.KeyGen_internal [FIPS-204] has to be invoked with the parsed value of xi as input.

6. SLH-DSA

Throughout this specification, "SLH-DSA" refers to the default pure and hedged version of SLH-DSA defined in [FIPS-205].

6.1. The SLH-DSA Algorithms

The following table lists the group of algorithm code points for the SLH-DSA signature scheme and the corresponding artifact lengths. This group of algorithms is henceforth referred to as "SLH-DSA code points".

6.1.1. Key Generation

SLH-DSA key generation is performed via the algorithm slh_keygen as specified in [FIPS-205], and the artifacts are encoded as fixed-length octet strings whose sizes are listed in Section 6.1.

6.1.2. Signature Generation

SLH-DSA signature generation is performed using the default hedged version of the slh_sign algorithm, as specified in [FIPS-205], with an empty context string ctx.

6.1.3. Signature Verification

SLH-DSA signature verification is performed using the slh_verify algorithm, as specified in [FIPS-205], with an empty context string ctx.

6.2. Packet Specifications

6.2.1. Signature Packet (Packet Type ID 2)

The SLH-DSA algorithms MUST be used only with v6 signatures, as defined in Section 5.2.3 of [].

The algorithm-specific part of a signature packet for an SLH-DSA code point consists of:

  • A fixed-length octet string of the SLH-DSA signature value whose length depends on the algorithm ID in the format specified in Table 8.

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 verifying implementation MUST reject any SLH-DSA signature that uses a hash algorithm with a smaller digest size.

6.2.2. Key Material Packets

The SLH-DSA code points MUST be used only with v6 keys, as defined in [], or newer versions defined by updates of that document.

6.2.2.1. Public Key Packets (Packet Type IDs 6 and 14)

The algorithm-specific part of the public key consists of:

  • A fixed-length octet string containing the SLH-DSA public key 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)

The algorithm-specific part of the secret key consists of:

  • A fixed-length octet string containing the SLH-DSA secret key whose length depends on the algorithm ID as specified in Table 8.

7. Notes on Algorithms

7.1. Symmetric Algorithms for SEIPD Packets

Implementations MUST implement AES-256. An implementation SHOULD use AES-256 in the case of a v1 Symmetrically Encrypted Integrity Protected Data (SEIPD) packet or AES-256 with any available Authenticated Encryption with Associated Data (AEAD) mode in the case of a v2 SEIPD packet, if all recipient certificates indicate support for it (explicitly or implicitly). This requirement is not specified as a MUST because it would render messages not using AES-256 invalid and subject to rejection upon decryption; however, a receiving implementation may not have access to all recipient certificates and, therefore, cannot reliably enforce such a requirement.

A certificate that contains a PQ(/T) key SHOULD include AES-256 in the "Preferred Symmetric Ciphers for v1 SEIPD" subpacket and SHOULD include the pair AES-256 with OCB in the "Preferred AEAD Ciphersuites" subpacket to make support for AES-256 and AES-256 with OCB explicit.

If AES-256 is not explicitly in the list of the "Preferred Symmetric 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 justified since AES-256 is mandatory to implement. If AES-128 is also implicitly added to the list, it is added after AES-256.

If the pair of AES-256 and OCB is not explicitly in the list of the "Preferred AEAD Ciphersuites" subpacket, and if the certificate 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 the pair of AES-128 and OCB is also implicitly added to the list, it is added after the pair of AES-256 and OCB.

7.2. Hash Algorithms for Key Binding Signatures

Subkey binding signatures (Signature Type 0x18) over algorithms described in this document MUST NOT be made with MD5, SHA-1, or RIPEMD-160. A receiving implementation MUST treat such a signature as invalid.

8. Migration Considerations

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 that extend the algorithm selection of []. During the transition period, the post-quantum algorithms will not be supported by all clients. Therefore, various migration considerations must be taken into account, particularly backwards compatibility to existing implementations that have not yet been updated to support the post-quantum algorithms.

8.1. Encrypting to Traditional and PQ(/T) Keys

During the transition to post-quantum cryptography, an implementation MAY, by default, encrypt messages to both PQ(/T) and traditional keys to avoid disruption to communications, optionally displaying a warning. As noted in Section 3.1, the confidentiality of a message is not post-quantum secure when using multiple PKESKs unless all of them use PQ(/T) encryption schemes.

8.2. Signing with Traditional and PQ(/T) Keys

The OpenPGP specification [] allows signing a message with multiple signatures. This implies the possibility of signing with both a PQ(/T) and a traditional key as described in Section 3.3. Note that signing with only PQ(/T) key material is not backwards compatible.

8.3. Verifying with Traditional and PQ(/T) Keys

When verifying, an implementation MAY be willing to accept signatures both from PQ(/T) keys and from traditional keys. A verifier concerned with a cryptographically relevant quantum computer with knowledge of a peer that has a PQ(/T) signing key MAY instead prefer to ignore all traditional signatures from that peer.

8.4. Generating PQ(/T) Keys

It is RECOMMENDED to generate fresh secrets when generating PQ(/T) keys. Note that reusing key material from existing ECC keys in PQ(/T) keys does not provide backwards compatibility.

9. Security Considerations

9.1. Security Aspects of Composite Signatures

When multiple signatures are applied to a message, the question of the protocol's resistance against signature-stripping attacks naturally arises. In a signature-stripping attack, an adversary 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. This amounts to a downgrade attack that potentially reduces the value of the signature. It should be noted that the composite signature schemes specified in this document are not subject to a signature-stripping vulnerability. This is due to the fact that, in any OpenPGP signature, the hashed metadata includes the signature algorithm ID, as specified in Section 5.2.4 of []. As a consequence, a component signature taken out of the context of a specific composite algorithm is not a valid OpenPGP signature for any message.

An attacker cannot generate a fresh valid signature for a message that has already been signed twice with the composite algorithm; being able to do so would violate Strong Unforgeability under Chosen Message Attack (SUF-CMA). Specifically, an attacker might try to construct a new signature by remixing the component parts of two legitimate composite signatures. That is impossible because each v6 signature embeds a random salt at the start of its hashed metadata. The two legitimate signatures use different salts, so their components are not interchangeable and cannot be recombined into a valid signature.

9.1.1. Preventing Signature Cross-Protocol Attacks

Signature cross-protocol attacks exploit the reuse of signatures across different protocols or contexts, allowing attackers to maliciously repurpose valid signatures in unintended ways. ML-DSA [FIPS-204], SLH-DSA [FIPS-205], and EdDSA [] support an optional context string parameter ctx that can be incorporated into the algorithm's internal message preprocessing step before signing and verification. In principle, this context parameter can contribute to the prevention of cross-protocol attacks. Nevertheless, this specification defines all these algorithms to use an empty context string, which is in accordance with the previous use of EdDSA in OpenPGP and maximizes interoperability with cryptographic libraries. In order to reliably prevent cross-protocol attacks, this specification recommends avoiding key-reuse across protocols in Section 8.4.

9.2. Key Combiner

A central security notion of a key combiner is IND-CCA2-security. It 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 Strong Diffie-Hellman problem in a nominal group holds. Note that Curve25519 and Curve448 qualify as such nominal groups [ABH_21].

Note that the inclusion of the ECC public key in the key combiner also accounts for multi-target attacks against X25519 and X448.

9.2.1. Domain Separation and Context Binding

The domSep information defined in Section 4.2.1 provides the domain separation for the key-combiner construction. This ensures that the input keying material is used to generate a KEK for a specific purpose. Appending the length octet ensures that no collisions can result across different domains, which might be defined in the future. This is because domSep || len(domSep) is guaranteed to 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 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 a string. Unambiguous parsability, in turn, ensures that no collisions can happen on the space of input strings to the key combiner.

The algorithm ID, passed as the algID parameter to multiKeyCombine, binds the derived KEK to the chosen algorithm. The algorithm ID unequivocally identifies the algorithm, the parameters for its instantiation, and the length of all artifacts, including the derived key.

9.3. ML-DSA and SLH-DSA Hedged Variants

This specification makes use of the default "hedged" variants of ML-DSA and SLH-DSA, which mix fresh randomness into the respective signature-generation algorithm's internal hashing step. This has the advantage of an enhanced side-channel resistance of the signature operations according to [FIPS-204] and [FIPS-205].

9.4. Minimum Digest Size for PQ(/T) Signatures

This specification requires that all PQ(/T) signatures defined in this document are made on message digests computed with a hash algorithm with at least 256 bits of digest size. Since all signature algorithms defined in this document require version 6 (or newer) signature packets, which currently include a leading random salt value in the hashed data, the required property is not collision but (second) preimage resistance. Therefore, a hash algorithm with a digest size of at least 256 bits is sufficient to match the targeted security levels of all PQ(/T) algorithms defined in this document.

9.5. Symmetric Algorithms for SEIPD Packets

This specification mandates support for AES-256 for two reasons. First, AES-KeyWrap with AES-256 is already part of the composite KEM construction. Second, some of the PQ(/T) algorithms target the security level of AES-256.

For the same reasons, this specification further recommends the use of AES-256 if it is supported by all recipient certificates, regardless of what the implementation would otherwise choose based on the recipients' preferences. This recommendation should be understood as a clear and simple rule for the selection of AES-256 for encryption. Implementations may also make more nuanced decisions.

9.6. Key Generation

When generating keys, this specification requires component keys to be generated independently and recommends not reusing existing keys for any of the components. Note that reusing a key across different protocols may lead to signature confusion vulnerabilities that formally classify as signature forgeries. Generally, reusing a key for different purposes may lead to subtle vulnerabilities.

9.7. Random Number Generation and Seeding

As mandated by Section 13.10 of [], all random data must be generated using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG).

10. Additional Considerations

10.1. Performance Considerations for SLH-DSA

This specification introduces both ML-DSA + EdDSA and SLH-DSA as PQ(/T) signature schemes.

Generally, ML-DSA + EdDSA provides a performance in terms of execution time requirements that is close to that of traditional ECC signature schemes. Regarding the size of signatures and public keys, though, ML-DSA has far greater requirements than traditional schemes like ECC-based or even RSA signature schemes.

Implementers may want to offer SLH-DSA for applications where the weaker security assumptions of a hash-based signature scheme are required -- namely only the second preimage resistance of a hash function; thus, a potentially higher degree of trust in the long-term security of signatures is achieved. However, SLH-DSA has performance characteristics in terms of execution time of the signature generation as well as space requirements for the signature that are even greater than those of ML-DSA + EdDSA signature schemes.

Pertaining to the execution time, the particularly costly operation in SLH-DSA is the signature generation. Depending on the parameter 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 performance measurements published in the NIST submissions for SLH-DSA and ML-DSA. In order to achieve fast signature generation times, the algorithm SLH-DSA-SHAKE-128f ("f" standing for "fast") should be chosen. This comes at the expense of a larger signature size. This choice can be relevant in applications where mass signing occurs or a small latency is required.

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 chosen. This comes at the expense of a longer signature generation time. In particular, SLH-DSA-SHAKE-128s achieves the smallest possible signature size, which is about the double size of an ML-DSA-87 signature. Where a higher security level than 128 bits is needed, SLH-DSA-SHAKE-256s can be used.

Unlike the signature generation time, the signature verification time of SLH-DSA is not that much larger than that of other PQC schemes. Based on the performance measurements published in the NIST submissions for SLH-DSA and ML-DSA, the verification time of SLH-DSA 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 (for -256s) to twelve (for -128f).

11. IANA Considerations

IANA has added the algorithm IDs listed below to the "OpenPGP Public Key Algorithms" registry at [IANA-OPENPGP].

ID:
30
Algorithm:
ML-DSA-65+Ed25519
Public Key Format:
32-octet Ed25519 public key (Table 6), 1952-octet ML-DSA-65 public key (Table 7)
Secret Key Format:
32-octet Ed25519 secret key (Table 6), 32-octet ML-DSA-65 secret key (Table 7)
Signature Format:
64-octet Ed25519 signature (Table 6), 3309-octet ML-DSA-65 signature (Table 7)
PKESK Format:
N/A
Reference:
Section 5
ID:
31
Algorithm:
ML-DSA-87+Ed448
Public Key Format:
57-octet Ed448 public key (Table 6), 2592-octet ML-DSA-87 public key (Table 7)
Secret Key Format:
57-octet Ed448 secret key (Table 6), 32-octet ML-DSA-87 secret key (Table 7)
Signature Format:
114-octet Ed448 signature (Table 6), 4627-octet ML-DSA-87 signature (Table 7)
PKESK Format:
N/A
Reference:
Section 5
ID:
32
Algorithm:
SLH-DSA-SHAKE-128s
Public Key Format:
32-octet public key (Table 8)
Secret Key Format:
64-octet secret key (Table 8)
Signature Format:
7856-octet signature (Table 8)
PKESK Format:
N/A
Reference:
Section 6.1
ID:
33
Algorithm:
SLH-DSA-SHAKE-128f
Public Key Format:
32-octet public key (Table 8)
Secret Key Format:
64-octet secret key (Table 8)
Signature Format:
17088-octet signature (Table 8)
PKESK Format:
N/A
Reference:
Section 6.1
ID:
34
Algorithm:
SLH-DSA-SHAKE-256s
Public Key Format:
64-octet public key (Table 8)
Secret Key Format:
128-octet secret key (Table 8)
Signature Format:
29792-octet signature (Table 8)
PKESK Format:
N/A
Reference:
Section 6.1
ID:
35
Algorithm:
ML-KEM-768+X25519
Public Key Format:
32-octet X25519 public key (Table 3), 1184-octet ML-KEM-768 public key (Table 4)
Secret Key Format:
32-octet X25519 secret key (Table 3), 64-octet ML-KEM-768 secret key (Table 4)
Signature Format:
N/A
PKESK Format:
32-octet X25519 ciphertext, 1088-octet ML-KEM-768 ciphertext, 1 octet remaining length, [1-octet algorithm ID in the case of v3 PKESK,] n octets wrapped session key (Section 4.3.1)
Reference:
Section 4
ID:
36
Algorithm:
ML-KEM-1024+X448
Public Key Format:
56-octet X448 public key (Table 3), 1568-octet ML-KEM-1024 public key (Table 4)
Secret Key Format:
56-octet X448 secret key (Table 3), 64-octet ML-KEM-1024 secret key (Table 4)
Signature Format:
N/A
PKESK Format:
56-octet X448 ciphertext, 1568-octet ML-KEM-1024 ciphertext, 1 octet remaining length, [1-octet algorithm ID in the case of v3 PKESK,] n octets wrapped session key (Section 4.3.1)
Reference:
Section 4

IANA has added 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.

12. References

12.1. Normative References

[FIPS-203]
, "Module-Lattice-Based Key-Encapsulation Mechanism Standard", NIST FIPS 203, DOI 10.6028/NIST.FIPS.203, , <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf>.
[FIPS-204]
NIST, "Module-Lattice-Based Digital Signature Standard", NIST FIPS 204, DOI 10.6028/NIST.FIPS.204, , <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf>.
[FIPS-205]
NIST, "Stateless Hash-Based Digital Signature Standard", NIST FIPS 205, DOI 10.6028/NIST.FIPS.205, , <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf>.
[IANA-OPENPGP]
IANA, "OpenPGP Public Key Algorithms", <https://www.iana.org/assignments/openpgp>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
[RFC3394]
Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, , <>.
[RFC7748]
Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, , <>.
[RFC8032]
Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, , <>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
[RFC9580]
Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe, "OpenPGP", RFC 9580, DOI 10.17487/RFC9580, , <>.

12.2. Informative References

[ABH_21]
Alwen, J., Blanchet, B., Hauck, E., Kiltz, E., Lipp, B., and D. Riepel, "Analysing the HPKE Standard", Advances in Cryptology - EUROCRYPT 2021, Lecture Notes in Computer Science, Vol. 12696, pp. 87-116, , <https://doi.org/10.1007/978-3-030-77870-5_4>.
[BCD_24]
Barbosa, M., Connolly, D., Duarte, J. D., Kaiser, A., Schwabe, P., Varner, K., and B. Westerbaan, "X-Wing The Hybrid KEM You've Been Looking For", IACR Communications in Cryptology, vol. 1, no. 1, , <https://doi.org/10.62056/a3qj89n4e>.
[CHHKM]
Connolly, D., Hövelmanns, K., Hülsing, A., Kousidis, S., and M. Meijers, "Starfighters - On the General Applicability of X-Wing", Cryptology ePrint Archive, Paper 2025/1397, , <https://eprint.iacr.org/2025/1397>.
[NIST-PQC]
NIST, "Post-Quantum Cryptography Standardization", , <https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization>.
[NISTIR-8413]
Alagic, G., Apon, D., Cooper, D., Dang, Q., Dang, T., Kelsey, J., Lichtinger, J., Liu, Y., Miller, C., Moody, D., Peralta, R., Perlner, R., Robinson, A., and D. Smith-Tone, "Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process", NIST IR 8413-upd1, , <https://doi.org/10.6028/NIST.IR.8413-upd1>.
[RFC9794]
Driscoll, F., Parsons, M., and B. Hale, "Terminology for Post-Quantum Traditional Hybrid Schemes", RFC 9794, DOI 10.17487/RFC9794, , <>.

Appendix A. Test Vectors

To help with implementing this specification, a set of non-normative examples follow.

A.1. Sample v6 Ed25519 with ML-KEM-768+X25519 Data

A.1.1. Transferable Secret Key

Here is a Transferable Secret Key consisting of:

  • A v6 Ed25519 Private Key packet

  • A v6 direct key self-signature

  • A User ID packet

  • A v6 positive certification self-signature

  • A v6 ML-KEM-768+X25519 Private Subkey packet

  • A v6 subkey binding signature

The primary key has the fingerprint c789e17d9dbdca7b3c833a3c063feb0353f80ad911fe27868fb0645df803e947.

The subkey has the fingerprint dafe0eebb2675ecfcdc20a23fe89ca5d12e83f527dfa354b6dcf662131a48b9d.

A.1.2. Transferable Public Key

Here is the corresponding Transferable Public Key for Appendix A.1.1 consisting of:

  • A v6 Ed25519 Public Key packet

  • A v6 direct key self-signature

  • A User ID packet

  • A v6 positive certification self-signature

  • A v6 ML-KEM-768+X25519 Public Subkey packet

  • A v6 subkey binding signature

A.1.3. Encrypted and Signed Message

Here is a signed message "Testing\n" encrypted to the certificate Appendix A.1.2 and signed by the secret key Appendix A.1.1:

  • A v6 PKESK

  • A v2 SEIPD

The hex-encoded mlkemKeyShare input to multiKeyCombine is b0e45408d8c713f3941cd27276f879e557df013e05bcf43e37d4c60266a4b797.

The hex-encoded ecdhKeyShare input to multiKeyCombine is 9d994741e0db5eacee44cb028c2ec48b1346feae2576aaac383bbcd64138c932.

The hex-encoded output of multiKeyCombine is 5bf078bf7977109db6dead92d3578b62d0ab0487ef84e8e0af08f4b4b229e590.

The hex-encoded session key is 94a3b8c9784463bb96b682cddf549adb23579b75bcb646f989d7cfe3e6e14435.

A.2. Sample v4 Ed25519 with ML-KEM-768+X25519 Data

A.2.1. Transferable Secret Key

Here is a Transferable Secret Key consisting of:

  • A v4 Ed25519 Private Key packet

  • A User ID packet

  • A v4 positive certification self-signature

  • A v4 ML-KEM-768+X25519 Private Subkey packet

  • A v4 subkey binding signature

The primary key has the fingerprint 342e5db2de345215cb2c944f7102ffed3b9cf12d.

The subkey has the fingerprint e51dbfea51936988b5428fffa4f95f985ed61a51.

A.2.2. Transferable Public Key

Here is the corresponding Transferable Public Key for Appendix A.2.1 consisting of:

  • A v4 Ed25519 Public Key packet

  • A User ID packet

  • A v4 positive certification self-signature

  • A v4 ML-KEM-768+X25519 Public Subkey packet

  • A v4 subkey binding signature

A.2.3. Encrypted and Signed SEIPD v1 Message

Here is a signed message "Testing\n" encrypted to the certificate Appendix A.2.2 and signed by the secret key Appendix A.2.1:

  • A v3 PKESK

  • A v1 SEIPD

The hex-encoded mlkemKeyShare input to multiKeyCombine is 16f2aea8ec1ca277c04cc7b87681d7d38511a38f554775a8fc4de41aa76eb586.

The hex-encoded ecdhKeyShare input to multiKeyCombine is 2fc0c8fcace9636c86d1ee1715a302819ad48c549579a462a33eed36627c532e.

The hex-encoded output of multiKeyCombine is c1591d7511f9f0213bfd57cf316e5ec0d40c4ea826fa989ab606aa3b8a1a2c1f.

The hex-encoded session key is b4dc7197e1519822ca689da484643edf272934d98ae1974b5d88317a7a6a3c4f.

A.2.4. Encrypted and Signed SEIPD v2 Message

Here is a signed message "Testing\n" encrypted to the certificate Appendix A.2.2 and signed by the secret key Appendix A.2.1:

  • A v6 PKESK

  • A v2 SEIPD

The hex-encoded mlkemKeyShare input to multiKeyCombine is 16a22adbeced91ada60b5561611748edd2fedc51e0770f86d7394870062e7322.

The hex-encoded ecdhKeyShare input to multiKeyCombine is 5ac67eab192f25ac99d87543e6fcd3a4769cb02c9d1afdc79354c2baa2289e29.

The hex-encoded output of multiKeyCombine is 5c5652a690b55d1e9545fbd722f838cd8ff4d3657af5a9026d02f3185ca74993.

The hex-encoded session key is 160867d96032b640208c1c92174d0270bb89189d72320711acd221bbea2a26b6.

A.3. Sample ML-DSA-65+Ed25519 with ML-KEM-768+X25519 Data

A.3.1. Transferable Secret Key

Here is a Transferable Secret Key consisting of:

  • A v6 ML-DSA-65+Ed25519 Private Key packet

  • A v6 direct key self-signature

  • A User ID packet

  • A v6 positive certification self-signature

  • A v6 ML-KEM-768+X25519 Private Subkey packet

  • A v6 subkey binding signature

The primary key has the fingerprint a3e2e14b6a493ff930fb27321f125e9a6880338be9fb7da3ae065ea65793242f.

The subkey has the fingerprint 7dae8fbce23022607167af72a002e774e0ca379a2d7ae072384e1e8fde3265e4.

A.3.2. Transferable Public Key

Here is the corresponding Transferable Public Key for Appendix A.3.1 consisting of:

  • A v6 ML-DSA-65+Ed25519 Public Key packet

  • A v6 direct key self-signature

  • A User ID packet

  • A v6 positive certification self-signature

  • A v6 ML-KEM-768+X25519 Public Subkey packet

  • A v6 subkey binding signature

A.3.3. Encrypted and Signed Message

Here is a signed message "Testing\n" encrypted to the certificate Appendix A.3.2 and signed by the secret key Appendix A.3.1:

  • A v6 PKESK

  • A v2 SEIPD

The hex-encoded mlkemKeyShare input to multiKeyCombine is 0987fe72ad5ea58e73344f9a2a543f4131d9fdb7cf07474f501430a20f705b4d.

The hex-encoded ecdhKeyShare input to multiKeyCombine is 88f3e9a8de1917127b4b758f6e83bd4ce00faaae01bd8b6e412a43a710b26012.

The hex-encoded output of multiKeyCombine is a4904982f7caa9c9de690afd772d8bfe027a1ad6a5bbda00db68963fe303ae8e.

The hex-encoded session key is adee68618b302d4bfd7ae3d432bc63a1c1ad7f5fd6e7fd7bdedbb0d0b14a5c9a.

A.3.4. Detached Signature

Here is a detached signature for the message "Testing\n" made by the secret key in Appendix A.3.1:

  • A v6 signature packet

A.4. Sample ML-DSA-87+Ed448 with ML-KEM-1024+X448 Data

A.4.1. Transferable Secret Key

Here is a Transferable Secret Key consisting of:

  • A v6 ML-DSA-87+Ed448 Private Key packet

  • A v6 direct key self-signature

  • A User ID packet

  • A v6 positive certification self-signature

  • A v6 ML-KEM-1024+X448 Private Subkey packet

  • A v6 subkey binding signature

The primary key has the fingerprint 0d7a8be1410cd68eed4845ab487b4b4cfaecd8ebad1a1166a84230499200ee20.

The subkey has the fingerprint 65090e147a8116ab7f62ab4ec7aae59d9e6532feb2af230c73cdc869fbc60c8f.

A.4.2. Transferable Public Key

Here is the corresponding Transferable Public Key for Appendix A.4.1 consisting of:

  • A v6 ML-DSA-87+Ed448 Public Key packet

  • A v6 direct key self-signature

  • A User ID packet

  • A v6 positive certification self-signature

  • A v6 ML-KEM-1024+X448 Public Subkey packet

  • A v6 subkey binding signature

A.4.3. Encrypted and Signed Message

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:

  • A v6 PKESK

  • A v2 SEIPD

The hex-encoded mlkemKeyShare input to multiKeyCombine is f18f161e617b8ce5968f109aadea1e7e1511d10165768d36127ba913c00637d2.

The hex-encoded ecdhKeyShare input to multiKeyCombine is 732860c8114ae84a964664b1f607785d11bc7d24d5324510adad89bd52db7ee0df99 82ad0d1669bdd05556330c86f2dae9e2edea42e05bc5.

The hex-encoded output of multiKeyCombine is ef1e32906f67d39bc800d90cabb0033c77ca6dce8ffca3e96d9c7348e2e8c16e.

The hex-encoded session key is 0588ce40b038aac353d1cf8c67a674b412985105794821013ef154f786c4d89d.

A.4.4. Detached Signature

Here is a detached signature for the message "Testing\n" made by the secret key Appendix A.4.1:

  • A v6 signature packet

A.5. Sample SLH-DSA-SHAKE-128s with ML-KEM-768+X25519 Data

A.5.1. Transferable Secret Key

Here is a Transferable Secret Key consisting of:

  • A v6 SLH-DSA-128s Private Key packet

  • A v6 direct key self-signature

  • A User ID packet

  • A v6 positive certification self-signature

  • A v6 ML-KEM-768+X25519 Private Subkey packet

  • A v6 subkey binding signature

The primary key has the fingerprint eed4d13fc36c78e48276a93233339c4dd230fd5f6f5c5b82c63d5c0b5e361d92.

The subkey has the fingerprint 3e8745a4bb488779e0f32480fa23f8d0bfd8c2f49d7f74e957e1c2ffc2ef4bfc.

A.5.2. Transferable Public Key

Here is the corresponding Transferable Public Key for Appendix A.5.1 consisting of:

  • A v6 SLH-DSA-128s Public Key packet

  • A v6 direct key self-signature

  • A User ID packet

  • A v6 positive certification self-signature

  • A v6 ML-KEM-768+X25519 Public Subkey packet

  • A v6 subkey binding signature

A.5.3. Encrypted and Signed Message

Here is a signed message "Testing\n" encrypted to the certificate Appendix A.5.2 and signed by the secret key Appendix A.5.1:

  • A v6 PKESK

  • A v2 SEIPD

The hex-encoded mlkemKeyShare input to multiKeyCombine is 5dc60150f5f965ddc8014b6aa2ecae1831467e98fa315422f238984d6421a22e.

The hex-encoded ecdhKeyShare input to multiKeyCombine is 9dbd0f9bde7fef09817146e53a0b5ce7d27e79612670968fa0025422c578ab55.

The hex-encoded output of multiKeyCombine is ae8ab57801911c04c7b4c2a2f665cf8d8a8188f948c2a65e39c292d9b1d86e32.

The hex-encoded session key is e87567cad8fee5738f92090feed009d8af95437fa664f94da98776d966bbbc52.

A.5.4. Detached Signature

Here is a detached signature for the message "Testing\n" made by the secret key Appendix A.5.1:

  • A v6 signature packet

A.6. Sample SLH-DSA-SHAKE-128f with ML-KEM-768+X25519 Data

A.6.1. Transferable Secret Key

Here is a Transferable Secret Key consisting of:

  • A v6 SLH-DSA-128f Private Key packet

  • A v6 direct key self-signature

  • A User ID packet

  • A v6 positive certification self-signature

  • A v6 ML-KEM-768+X25519 Private Subkey packet

  • A v6 subkey binding signature

The primary key has the fingerprint d54e0307021169f7b88beb2b76e3aad0e114be1a8f982d74dba9ca51d03537f4.

The subkey has the fingerprint d8875664256c382dd7f3a5ce05021088922811f5d0b1a1f8c7769944a51b7002.

A.6.2. Transferable Public Key

Here is the corresponding Transferable Public Key for Appendix A.6.1 consisting of:

  • A v6 SLH-DSA-128f Public Key packet

  • A v6 direct key self-signature

  • A User ID packet

  • A v6 positive certification self-signature

  • A v6 ML-KEM-768+X25519 Public Subkey packet

  • A v6 subkey binding signature

A.6.3. Detached Signature

Here is a detached signature for the message "Testing\n" made by the secret key Appendix A.6.1:

  • A v6 signature packet

A.7. Sample SLH-DSA-SHAKE-256s with ML-KEM-1024+X448 Data

A.7.1. Transferable Secret Key

Here is a Transferable Secret Key consisting of:

  • A v6 SLH-DSA-256s Private Key packet

  • A v6 direct key self-signature

  • A User ID packet

  • A v6 positive certification self-signature

  • A v6 ML-KEM-1024+X448 Private Subkey packet

  • A v6 subkey binding signature

The primary key has the fingerprint 72fff84863aeba67f0d1d7691173247dd427533b9d7ee76011c6f77f2ce9fa7a.

The subkey has the fingerprint 570a5bbab93169876a8240da35a1ada7ba8a640aabe3ab467c797214844df15f.

A.7.2. Transferable Public Key

Here is the corresponding Transferable Public Key for Appendix A.7.1 consisting of:

  • A v6 SLH-DSA-256s Public Key packet

  • A v6 direct key self-signature

  • A User ID packet

  • A v6 positive certification self-signature

  • A v6 ML-KEM-1024+X448 Public Subkey packet

  • A v6 subkey binding signature

A.7.3. Detached Signature

Here is a detached signature for the message "Testing\n" made by the secret key Appendix A.7.1:

  • A v6 signature packet

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

Stavros Kousidis

BSI

Germany

Johannes Roth

MTG AG

Germany

Falko Strenzke

MTG AG

Germany

Aron Wussler

Proton AG

Switzerland