InternetDraft  PQC in OpenPGP  January 2024 
Kousidis, et al.  Expires 2 August 2024  [Page] 
 Workgroup:
 Network Working Group
 InternetDraft:
 draftwussleropenpgppqc04
 Published:
 Intended Status:
 Informational
 Expires:
PostQuantum Cryptography in OpenPGP
Abstract
This document defines a postquantum publickey algorithm extension for the OpenPGP protocol. Given the generally assumed threat of a cryptographically relevant quantum computer, this extension provides a basis for longterm secure OpenPGP signatures and ciphertexts. Specifically, it defines composite publickey encryption based on MLKEM (formerly CRYSTALSKyber), composite publickey signatures based on MLDSA (formerly CRYSTALSDilithium), both in combination with elliptic curve cryptography, and SLHDSA (formerly SPHINCS+) as a standalone public key signature scheme.¶
About This Document
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draftwussleropenpgppqc/.¶
Discussion of this document takes place on the WG Working Group mailing list (mailto:openpgp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/openpgp/. Subscribe at https://www.ietf.org/mailman/listinfo/openpgp/.¶
Source for this draft and an issue tracker can be found at https://github.com/openpgppqc/draftopenpgppqc.¶
Status of This Memo
This InternetDraft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
InternetDrafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as InternetDrafts. The list of current InternetDrafts is at https://datatracker.ietf.org/drafts/current/.¶
InternetDrafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use InternetDrafts as reference material or to cite them other than as "work in progress."¶
This InternetDraft will expire on 2 August 2024.¶
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/licenseinfo) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
1. Introduction
The OpenPGP protocol supports various traditional publickey 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 by algorithms that remain secure in the presence of quantum computers.¶
Such cryptographic algorithms are referred to as postquantum cryptography. The algorithms defined in this extension were chosen for standardization by the National Institute of Standards and Technology (NIST) in mid 2022 [NISTIR8413] as the result of the NIST PostQuantum Cryptography Standardization process initiated in 2016 [NISTPQC]. Namely, these are MLKEM (formerly CRYSTALSKyber) as a Key Encapsulation Mechanism (KEM), a KEM being a modern building block for publickey encryption, and MLDSA (formerly CRYSTALSDilithium) as well as SLHDSA (formerly SPHINCS+) as signature schemes.¶
For the two ML* schemes, this document follows the conservative strategy to deploy postquantum in combination with traditional schemes such that the security is retained even if all schemes but one in the combination are broken. In contrast, the stateless hashbased signature scheme SLHDSA 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: SLHDSA standalone and the two ML* as composite with ECCbased KEM 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 single data structure or algorithm from the protocol perspective.¶
The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension and the newly defined algorithms or algorithm combinations.¶
1.1. Conventions used in this Document
1.1.1. Terminology for MultiAlgorithm Schemes
The terminology in this document is oriented towards the definitions in [draftdriscollpqthybridterminology]. Specifically, the terms "multialgorithm", "composite" and "noncomposite" are used in correspondence with the definitions therein. The abbreviation "PQ" is used for postquantum schemes. To denote the combination of postquantum and traditional schemes, the abbreviation "PQ/T" is used. The short form "PQ(/T)" stands for PQ or PQ/T.¶
1.2. PostQuantum Cryptography
This section describes the individual postquantum cryptographic schemes. All schemes listed here are believed to provide security in the presence of a cryptographically relevant quantum computer. However, the mathematical problems on which the two ML* schemes and SLHDSA are based, are fundamentally different, and accordingly the level of trust commonly placed in them as well as their performance characteristics vary.¶
[Note to the reader: This specification refers to the NIST PQC draft standards FIPS 203, FIPS 204, and FIPS 205 as if they were a final specification. This is a temporary solution until the final versions of these documents are available. The goal is to provide a sufficiently precise specification of the algorithms already at the draft stage of this specification, so that it is possible for implementers to create interoperable implementations. Furthermore, we want to point out that, depending on possible future changes to the draft standards by NIST, this specification may be updated as soon as corresponding information becomes available.]¶
1.2.1. MLKEM
MLKEM [FIPS203] is based on the hardness of solving the learningwitherrors problem in module lattices (MLWE). The scheme is believed to provide security against cryptanalytic attacks by classical as well as quantum computers. This specification defines MLKEM only in composite combination with ECCbased encryption schemes in order to provide a prequantum security fallback.¶
1.2.2. MLDSA
MLDSA [FIPS204] is a signature scheme that, like MLKEM, 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 MLDSA in composite combination with ECCbased signature schemes.¶
1.2.3. SLHDSA
SLHDSA [FIPS205] is a stateless hashbased 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 SLHDSA as a standalone signature scheme.¶
In deployments the performance characteristics of SLHDSA should be taken into account. We refer to Section 10.1 for a discussion of the performance characteristics of this scheme.¶
1.3. Elliptic Curve Cryptography
The ECCbased encryption is defined here as a KEM. This is in contrast to [ID.ietfopenpgpcryptorefresh] where the ECCbased encryption is defined as a publickey encryption scheme.¶
All elliptic curves for the use in the composite combinations are taken from [ID.ietfopenpgpcryptorefresh]. However, as explained in the following, in the case of Curve25519 encoding changes are applied to the new composite schemes.¶
1.3.1. Curve25519 and Curve448
Curve25519 and Curve448 are defined in [RFC7748] for use in a DiffieHellman key agreement scheme and defined in [RFC8032] for use in a digital signature scheme. For Curve25519 this specification adapts the encoding of objects as defined in [RFC7748] in contrast to [ID.ietfopenpgpcryptorefresh].¶
1.3.2. Generic Prime Curves
For interoperability this extension offers CRYSTALS* in composite combinations with the NIST curves P256, P384 defined in [SP800186] and the Brainpool curves brainpoolP256r1, brainpoolP384r1 defined in [RFC5639].¶
1.4. Standalone and MultiAlgorithm Schemes
This section provides a categorization of the new algorithms and their combinations.¶
1.4.1. Standalone and Composite MultiAlgorithm Schemes
This specification introduces new cryptographic schemes, which can be categorized as follows:¶

PQ/T multialgorithm publickey encryption, namely a composite combination of MLKEM with an ECCbased KEM,¶

PQ/T multialgorithm digital signature, namely composite combinations of MLDSA with ECCbased signature schemes,¶

PQ digital signature, namely SLHDSA as a standalone cryptographic algorithm.¶
For each of the composite schemes, this specification mandates that the recipient has to successfully perform the cryptographic algorithms for each of the component schemes used in a cryptrographic message, in order for the message to be deciphered and considered as valid. This means that all component signatures must be verified successfully in order to achieve a successful verification of the composite signature. In the case of the composite publickey decryption, each of the component KEM decapsulation operations must succeed.¶
1.4.2. NonComposite Algorithm Combinations
As the OpenPGP protocol [ID.ietfopenpgpcryptorefresh] allows for multiple signatures to be applied to a single message, it is also possible to realize noncomposite combinations of signatures. Furthermore, multiple OpenPGP signatures may be combined on the application layer. These latter two cases realize noncomposite combinations of signatures. Section 4.4 specifies how implementations should handle the verification of such combinations of signatures.¶
Furthermore, the OpenPGP protocol also allows for parallel encryption to different keys held by the same recipient. Accordingly, if the sender makes use of this feature and sends an encrypted message with multiple PKESK packages for different encryption keys held by the same recipient, a noncomposite multialgorithm publickey encryption is realized where the recipient has to decrypt only one of the PKESK packages in order to decrypt the message. See Section 4.2 for restrictions on parallel encryption mandated by this specification.¶
2. Preliminaries
This section provides some preliminaries for the definitions in the subsequent sections.¶
2.1. Elliptic curves
2.1.1. 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:¶
B = 04  X  Y¶
where X
and Y
are coordinates of the elliptic curve point P = (X, Y)
, and
each coordinate is encoded in the bigendian format and zeropadded to the
adjusted underlying field size. The adjusted underlying field size is the
underlying field size rounded up to the nearest 8bit boundary, as noted in the
"Field size" column in Table 6,
Table 7, or Table 11. This encoding is
compatible with the definition given in [SEC1].¶
2.1.2. 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 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.¶
Furthermore, when performing the explicitly listed operations in Section 5.1.1.1, Section 5.1.1.2 or Section 5.1.1.3 it is REQUIRED to follow the specification and security advisory mandated from the respective elliptic curve specification.¶
3. Supported Public Key Algorithms
This section specifies the composite MLKEM + ECC and MLDSA + ECC schemes as well as the standalone SLHDSA signature scheme. The composite schemes are fully specified via their algorithm ID. The SLHDSA signature schemes are fully specified by their algorithm ID and an additional parameter ID.¶
3.1. Algorithm Specifications
For encryption, the following composite KEM schemes are specified:¶
ID  Algorithm  Requirement  Definition 

29  MLKEM768 + X25519  MUST  Section 5.2 
30  MLKEM1024 + X448  SHOULD  Section 5.2 
31  MLKEM768 + ECDHNISTP256  MAY  Section 5.2 
32  MLKEM1024 + ECDHNISTP384  MAY  Section 5.2 
33  MLKEM768 + ECDHbrainpoolP256r1  MAY  Section 5.2 
34  MLKEM1024 + ECDHbrainpoolP384r1  MAY  Section 5.2 
For signatures, the following (composite) signature schemes are specified:¶
ID  Algorithm  Requirement  Definition 

35  MLDSA65 + Ed25519  MUST  Section 6.2 
36  MLDSA87 + Ed448  SHOULD  Section 6.2 
37  MLDSA65 + ECDSANISTP256  MAY  Section 6.2 
38  MLDSA87 + ECDSANISTP384  MAY  Section 6.2 
39  MLDSA65 + ECDSAbrainpoolP256r1  MAY  Section 6.2 
40  MLDSA87 + ECDSAbrainpoolP384r1  MAY  Section 6.2 
41  SLHDSASHA2  SHOULD  Section 7.1 
42  SLHDSASHAKE  MAY  Section 7.1 
3.2. Parameter Specification
3.2.1. SLHDSASHA2
For the SLHDSASHA2 signature algorithm from Table 2, the following parameters are specified:¶
Parameter ID  Parameter 

1  SLHDSASHA2128s 
2  SLHDSASHA2128f 
3  SLHDSASHA2192s 
4  SLHDSASHA2192f 
5  SLHDSASHA2256s 
6  SLHDSASHA2256f 
All security parameters inherit the requirement of SLHDSASHA2 from
Table 2. That is, implementations SHOULD implement the parameters
specified in Table 3. The values 0x00
and 0xFF
are reserved
for future extensions.¶
3.2.2. SLHDSASHAKE
For the SLHDSASHAKE signature algorithm from Table 2, the following parameters are specified:¶
Parameter ID  Parameter 

1  SLHDSASHAKE128s 
2  SLHDSASHAKE128f 
3  SLHDSASHAKE192s 
4  SLHDSASHAKE192f 
5  SLHDSASHAKE256s 
6  SLHDSASHAKE256f 
All security parameters inherit the requirement of SLHDSASHAKE from
Table 2. That is, implementations MAY implement the parameters
specified in Table 4. The values 0x00
and 0xFF
are reserved
for future extensions.¶
4. Algorithm Combinations
4.1. Composite KEMs
The MLKEM + ECC publickey encryption involves both the MLKEM and an ECCbased KEM in an a priori nonseparable manner. This is achieved via KEM combination, i.e. 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.¶
4.2. Parallel PublicKey Encryption
As explained in Section 1.4.2, the OpenPGP protocol inherently supports parallel encryption to different keys of the same recipient. Implementations MUST NOT encrypt a message with a purely traditional publickey encryption key of a recipient if it is encrypted with a PQ/T key of the same recipient.¶
4.3. Composite Signatures
The MLDSA + ECC signature consists of independent MLDSA and ECC signatures, and an implementation MUST successfully validate both signatures to state that the MLDSA + ECC signature is valid.¶
4.4. Multiple Signatures
The OpenPGP message format allows multiple signatures of a message, i.e. 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 [ID.ietfopenpgpcryptorefresh] Section 5.2.5, 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 nonignored signatures validates successfully.¶
[Note to the reader: The last requirement, that one valid signature is sufficient to identify a message as correctly signed, is an interpretation of [ID.ietfopenpgpcryptorefresh] Section 5.2.5.]¶
5. Composite KEM schemes
5.1. Building Blocks
5.1.1. ECCBased KEMs
In this section we define the encryption, decryption, and data formats for the ECDH component of the composite algorithms.¶
Table 5, Table 6, and Table 7 describe the ECCKEM parameters and artifact lengths. The artefacts in Table 5 follow the encodings described in [RFC7748].¶
X25519  X448  

Algorithm ID reference  29  30 
Field size  32 octets  56 octets 
ECCKEM  x25519Kem (Section 5.1.1.1)  x448Kem (Section 5.1.1.2) 
ECDH public key  32 octets [RFC7748]  56 octets [RFC7748] 
ECDH secret key  32 octets [RFC7748]  56 octets [RFC7748] 
ECDH ephemeral  32 octets [RFC7748]  56 octets [RFC7748] 
ECDH share  32 octets [RFC7748]  56 octets [RFC7748] 
Key share  32 octets  64 octets 
Hash  SHA3256  SHA3512 
NIST P256  NIST P384  

Algorithm ID reference  31  32 
Field size  32 octets  48 octets 
ECCKEM  ecdhKem (Section 5.1.1.3)  ecdhKem (Section 5.1.1.3) 
ECDH public key  65 octets of SEC1encoded public point  97 octets of SEC1encoded public point 
ECDH secret key  32 octets bigendian encoded secret scalar  48 octets bigendian encoded secret scalar 
ECDH ephemeral  65 octets of SEC1encoded ephemeral point  97 octets of SEC1encoded ephemeral point 
ECDH share  65 octets of SEC1encoded shared point  97 octets of SEC1encoded shared point 
Key share  32 octets  64 octets 
Hash  SHA3256  SHA3512 
brainpoolP256r1  brainpoolP384r1  

Algorithm ID reference  33  34 
Field size  32 octets  48 octets 
ECCKEM  ecdhKem (Section 5.1.1.3)  ecdhKem (Section 5.1.1.3) 
ECDH public key  65 octets of SEC1encoded public point  97 octets of SEC1encoded public point 
ECDH secret key  32 octets bigendian encoded secret scalar  48 octets bigendian encoded secret scalar 
ECDH ephemeral  65 octets of SEC1encoded ephemeral point  97 octets of SEC1encoded ephemeral point 
ECDH share  65 octets of SEC1encoded shared point  97 octets of SEC1encoded shared point 
Key share  32 octets  64 octets 
Hash  SHA3256  SHA3512 
The SEC1 format for point encoding is defined in Section 2.1.1.¶
The various procedures to perform the operations of an ECCbased KEM are defined in the following subsections. Specifically, each of these subsections defines the instances of the following operations:¶
(eccCipherText, eccKeyShare) < ECCKEM.Encaps(eccPublicKey)¶
and¶
(eccKeyShare) < ECCKEM.Decaps(eccSecretKey, eccCipherText)¶
To instantiate ECCKEM
, one must select a parameter set from
Table 5, Table 6, or
Table 7.¶
5.1.1.1. X25519KEM
The encapsulation and decapsulation operations of x25519kem
are described
using the function X25519()
and encodings defined in [RFC7748]. The
eccSecretKey
is denoted as r
, the eccPublicKey
as R
, they are subject
to the equation R = X25519(r, U(P))
. Here, U(P)
denotes the ucoordinate of
the base point of Curve25519.¶
The operation x25519Kem.Encaps()
is defined as follows:¶

Generate an ephemeral key pair {
v
,V
} viaV = X25519(v,U(P))
wherev
is a random scalar¶ 
Compute the shared coordinate
X = X25519(v, R)
whereR
is the public keyeccPublicKey
¶ 
Set the output
eccCipherText
toV
¶ 
Set the output
eccKeyShare
toSHA3256(X  eccCipherText  eccPublicKey)
¶
The operation x25519Kem.Decaps()
is defined as follows:¶
5.1.1.2. X448KEM
The encapsulation and decapsulation operations of x448kem
are described using
the function X448()
and encodings defined in [RFC7748]. The eccSecretKey
is denoted as r
, the eccPublicKey
as R
, they are subject to the equation
R = X25519(r, U(P))
. Here, U(P)
denotes the ucoordinate of the base point
of Curve448.¶
The operation x448.Encaps()
is defined as follows:¶

Generate an ephemeral key pair {
v
,V
} viaV = X448(v,U(P))
wherev
is a random scalar¶ 
Compute the shared coordinate
X = X448(v, R)
whereR
is the public keyeccPublicKey
¶ 
Set the output
eccCipherText
toV
¶ 
Set the output
eccKeyShare
toSHA3512(X  eccCipherText  eccPublicKey)
¶
The operation x448Kem.Decaps()
is defined as follows:¶
5.1.1.3. ECDHKEM
The operation ecdhKem.Encaps()
is defined as follows:¶

Generate an ephemeral key pair {
v
,V=vG
} as defined in [SP800186] or [RFC5639] wherev
is a random scalar¶ 
Compute the shared point
S = vR
, whereR
is the component public keyeccPublicKey
, according to [SP800186] or [RFC5639]¶ 
Extract the
X
coordinate from the SEC1 encoded pointS = 04  X  Y
as defined in section Section 2.1.1¶ 
Set the output
eccCipherText
to the SEC1 encoding ofV
¶ 
Set the output
eccKeyShare
toHash(X  eccCipherText  eccPublicKey)
, withHash
chosen according to Table 6 or Table 7¶
The operation ecdhKem.Decaps()
is defined as follows:¶

Compute the shared Point
S
asrV
, wherer
is theeccSecretKey
andV
is theeccCipherText
, according to [SP800186] or [RFC5639]¶ 
Extract the
X
coordinate from the SEC1 encoded pointS = 04  X  Y
as defined in section Section 2.1.1¶ 
Set the output
eccKeyShare
toHash(X  eccCipherText  eccPublicKey)
, withHash
chosen according to Table 6 or Table 7¶
5.1.2. MLKEM
MLKEM features the following operations:¶
(mlkemCipherText, mlkemKeyShare) < MLKEM.Encaps(mlkemPublicKey)¶
and¶
(mlkemKeyShare) < MLKEM.Decaps(mlkemCipherText, mlkemSecretKey)¶
The above are the operations MLKEM.Encaps
and MLKEM.Decaps
defined in
[FIPS203]. Note that mlkemPublicKey
is the encapsulation and
mlkemSecretKey
is the decapsulation key.¶
MLKEM has the parameterization with the corresponding artifact lengths in octets as given in Table 8. All artifacts are encoded as defined in [FIPS203].¶
Algorithm ID reference  MLKEM  Public key  Secret key  Ciphertext  Key share 

29, 31, 33  MLKEM768  1184  2400  1088  32 
30, 32, 34  MLKEM1024  1568  3168  1568  32 
To instantiate MLKEM
, one must select a parameter set from the column
"MLKEM" of Table 8.¶
The procedure to perform MLKEM.Encaps()
is as follows:¶

Extract the encapsulation key
mlkemPublicKey
that is part of the recipient's composite public key¶ 
Invoke
(mlkemCipherText, mlkemKeyShare) < MLKEM.Encaps(mlkemPublicKey)
¶ 
Set
mlkemCipherText
as the MLKEM ciphertext¶ 
Set
mlkemKeyShare
as the MLKEM symmetric key share¶
The procedure to perform MLKEM.Decaps()
is as follows:¶
5.2. Composite Encryption Schemes with MLKEM
Table 1 specifies the following MLKEM + ECC composite publickey encryption schemes:¶
Algorithm ID reference  MLKEM  ECCKEM  ECCKEM curve 

29  MLKEM768  x25519Kem  Curve25519 
30  MLKEM1024  x448Kem  Curve448 
31  MLKEM768  ecdhKem  NIST P256 
32  MLKEM1024  ecdhKem  NIST P384 
33  MLKEM768  ecdhKem  brainpoolP256r1 
34  MLKEM1024  ecdhKem  brainpoolP384r1 
The MLKEM + ECC composite publickey encryption schemes are built according to the following principal design:¶

The MLKEM encapsulation algorithm is invoked to create a MLKEM ciphertext together with a MLKEM symmetric key share.¶

The encapsulation algorithm of an ECCbased KEM, namely one out of X25519KEM, X448KEM, or ECDHKEM is invoked to create an ECC ciphertext together with an ECC symmetric key share.¶

A KeyEncryptionKey (KEK) is computed as the output of a key combiner that receives as input both of the above created symmetric key shares and the protocol binding information.¶

The session key for content encryption is then wrapped as described in [RFC3394] using AES256 as algorithm and the KEK as key.¶

The PKESK package's algorithmspecific parts are made up of the MLKEM ciphertext, the ECC ciphertext, and the wrapped session key.¶
5.2.1. Fixed information
For the composite KEM schemes defined in Table 1 the following procedure, justified in Section 9.3, MUST be used to derive a string to use as binding between the KEK and the communication parties.¶
// Input: // algID  the algorithm ID encoded as octet fixedInfo = algID¶
5.2.2. Key combiner
For the composite KEM schemes defined in Table 1 the following procedure MUST be used to compute the KEK that wraps a session key. The construction is a onestep key derivation function compliant to [SP80056C] Section 4, based on KMAC256 [SP800185]. It is given by the following algorithm.¶
// multiKeyCombine(eccKeyShare, eccCipherText, // mlkemKeyShare, mlkemCipherText, // fixedInfo, oBits) // // Input: // eccKeyShare  the ECC key share encoded as an octet string // eccCipherText  the ECC ciphertext encoded as an octet string // mlkemKeyShare  the MLKEM key share encoded as an octet string // mlkemCipherText  the MLKEM ciphertext encoded as an octet string // fixedInfo  the fixed information octet string // oBits  the size of the output keying material in bits // // Constants: // domSeparation  the UTF8 encoding of the string // "OpenPGPCompositeKeyDerivationFunction" // counter  the fixed 4 byte value 0x00000001 // customizationString  the UTF8 encoding of the string "KDF" eccData = eccKeyShare  eccCipherText mlkemData = mlkemKeyShare  mlkemCipherText encData = counter  eccData  mlkemData  fixedInfo MB = KMAC256(domSeparation, encData, oBits, customizationString)¶
Note that the values eccKeyShare
defined in Section 5.1.1 and mlkemKeyShare
defined in Section 5.1.2 already use the relative ciphertext in the
derivation. The ciphertext is by design included again in the key combiner to
provide a robust security proof.¶
The value of domSeparation
is the UTF8 encoding of the string
"OpenPGPCompositeKeyDerivationFunction" and MUST be the following octet sequence:¶
domSeparation := 4F 70 65 6E 50 47 50 43 6F 6D 70 6F 73 69 74 65 4B 65 79 44 65 72 69 76 61 74 69 6F 6E 46 75 6E 63 74 69 6F 6E¶
The value of counter
MUST be set to the following octet sequence:¶
counter := 00 00 00 01¶
The value of fixedInfo
MUST be set according to Section 5.2.1.¶
The value of customizationString
is the UTF8 encoding of the string "KDF"
and MUST be set to the following octet sequence:¶
customizationString := 4B 44 46¶
5.2.3. Key generation procedure
The implementation MUST independently generate the MLKEM and the ECC component keys. MLKEM key generation follows the specification [FIPS203] and the artifacts are encoded as fixedlength octet strings as defined in Section 5.1.2. For ECC this is done following the relative specification in [RFC7748], [SP800186], or [RFC5639], and encoding the outputs as fixedlength octet strings in the format specified in Table 5, Table 6, or Table 7.¶
5.2.4. Encryption procedure
The procedure to perform publickey encryption with a MLKEM + ECC composite scheme is as follows:¶

Take the recipient's authenticated publickey packet
pkComposite
andsessionKey
as input¶ 
Parse the algorithm ID from
pkComposite
¶ 
Extract the
eccPublicKey
andmlkemPublicKey
component from the algorithm specific data encoded inpkComposite
with the format specified in Section 5.3.2.¶ 
Instantiate the ECCKEM and the MLKEM depending on the algorithm ID according to Table 9¶

Compute
(eccCipherText, eccKeyShare) := ECCKEM.Encaps(eccPublicKey)
¶ 
Compute
(mlkemCipherText, mlkemKeyShare) := MLKEM.Encaps(mlkemPublicKey)
¶ 
Compute
fixedInfo
as specified in Section 5.2.1¶ 
Compute
KEK := multiKeyCombine(eccKeyShare, eccCipherText, mlkemKeyShare, mlkemCipherText, fixedInfo, oBits=256)
as defined in Section 5.2.2¶ 
Compute
C := AESKeyWrap(KEK, sessionKey)
with AES256 as per [RFC3394] that includes a 64 bit integrity check¶ 
Output
eccCipherText  mlkemCipherText  len(C)  C
¶
5.2.5. Decryption procedure
The procedure to perform publickey decryption with a MLKEM + ECC composite scheme is as follows:¶

Take the matching PKESK and own secret key packet as input¶

From the PKESK extract the algorithm ID and the
encryptedKey
¶ 
Check that the own and the extracted algorithm ID match¶

Parse the
eccSecretKey
andmlkemSecretKey
from the algorithm specific data of the own secret key encoded in the format specified in Section 5.3.2¶ 
Instantiate the ECCKEM and the MLKEM depending on the algorithm ID according to Table 9¶

Parse
eccCipherText
,mlkemCipherText
, andC
fromencryptedKey
encoded aseccCipherText  mlkemCipherText  len(C)  C
as specified in Section 5.3.1¶ 
Compute
(eccKeyShare) := ECCKEM.Decaps(eccCipherText, eccSecretKey)
¶ 
Compute
(mlkemKeyShare) := MLKEM.Decaps(mlkemCipherText, mlkemSecretKey)
¶ 
Compute
fixedInfo
as specified in Section 5.2.1¶ 
Compute
KEK := multiKeyCombine(eccKeyShare, eccCipherText, mlkemKeyShare, mlkemCipherText, fixedInfo, oBits=256)
as defined in Section 5.2.2¶ 
Compute
sessionKey := AESKeyUnwrap(KEK, C)
with AES256 as per [RFC3394], aborting if the 64 bit integrity check fails¶ 
Output
sessionKey
¶
5.3. Packet specifications
5.3.1. PublicKey Encrypted Session Key Packets (Tag 1)
The algorithmspecific fields consists of:¶

A fixedlength octet string representing an ECC ephemeral public key in the format associated with the curve as specified in Section 5.1.1.¶

A fixedlength octet string of the MLKEM ciphertext, whose length depends on the algorithm ID as specified in Table 8.¶

The oneoctet algorithm identifier, if it is passed (in the case of a v3 PKESK packet).¶

A variablelength field containing the wrapped session key:¶

A oneoctet size of the following field;¶

The wrapped session key represented as an octet string, i.e., the output of the encryption procedure described in Section 5.2.4.¶

Note that unlike most publickey algorithms, in the case of a v3 PKESK packet, the symmetric algorithm identifier is not encrypted. Instead, it is prepended to the encrypted session key in plaintext. In this case, the symmetric algorithm used MUST be AES128, AES192 or AES256 (algorithm ID 7, 8 or 9).¶
5.3.2. Key Material Packets
The algorithmspecific public key is this series of values:¶

A fixedlength octet string representing an EC point public key, in the point format associated with the curve specified in Section 5.1.1.¶

A fixedlength octet string containing the MLKEM public key, whose length depends on the algorithm ID as specified in Table 8.¶
The algorithmspecific secret key is these two values:¶

A fixedlength octet string of the encoded secret scalar, whose encoding and length depend on the algorithm ID as specified in Section 5.1.1.¶

A fixedlength octet string containing the MLKEM secret key, whose length depends on the algorithm ID as specified in Table 8.¶
6. Composite Signature Schemes
6.1. Building blocks
6.1.1. EdDSABased signatures
To sign and verify with EdDSA the following operations are defined:¶
(eddsaSignature) < EdDSA.Sign(eddsaSecretKey, dataDigest)¶
and¶
(verified) < EdDSA.Verify(eddsaPublicKey, eddsaSignature, dataDigest)¶
The public and secret key, as well as the signature MUST be encoded according to [RFC8032] as fixedlength octet strings. The following table describes the EdDSA parameters and artifact lengths:¶
Algorithm ID reference  Curve  Field size  Public key  Secret key  Signature 

35  Ed25519  32  32  32  64 
36  Ed448  57  57  57  114 
6.1.2. ECDSABased signatures
To sign and verify with ECDSA the following operations are defined:¶
(ecdsaSignatureR, ecdsaSignatureS) < ECDSA.Sign(ecdsaSecretKey, dataDigest)¶
and¶
(verified) < ECDSA.Verify(ecdsaPublicKey, ecdsaSignatureR, ecdsaSignatureS, dataDigest)¶
The public keys MUST be encoded in SEC1 format as defined in section
Section 2.1.1. The secret key, as well as both values R
and S
of the
signature MUST each be encoded as a bigendian integer in a fixedlength octet
string of the specified size.¶
The following table describes the ECDSA parameters and artifact lengths:¶
Algorithm ID reference  Curve  Field size  Public key  Secret key  Signature value R  Signature value S 

37  NIST P256  32  65  32  32  32 
38  NIST P384  48  97  48  48  48 
39  brainpoolP256r1  32  65  32  32  32 
40  brainpoolP384r1  48  97  48  48  48 
6.1.3. MLDSA signatures
For MLDSA signature generation the default hedged version of MLDSA.Sign
given in [FIPS204] is used. That is, to sign with MLDSA the following
operation is defined:¶
(mldsaSignature) < MLDSA.Sign(mldsaSecretKey, dataDigest)¶
For MLDSA signature verification the algorithm MLDSA.Verify given in [FIPS204] is used. That is, to verify with MLDSA the following operation is defined:¶
(verified) < MLDSA.Verify(mldsaPublicKey, dataDigest, mldsaSignature)¶
MLDSA has the parameterization with the corresponding artifact lengths in octets as given in Table 12. All artifacts are encoded as defined in [FIPS204].¶
Algorithm ID reference  MLDSA  Public key  Secret key  Signature value 

35, 37, 39  MLDSA65  1952  4000  3293 
36, 38, 40  MLDSA87  2592  4864  4595 
6.2. Composite Signature Schemes with MLDSA
6.2.1. Signature data digest
Signature data (i.e. the data to be signed) is digested prior to signing operations, see [ID.ietfopenpgpcryptorefresh] Section 5.2.4. Composite MLDSA + ECC signatures MUST use the associated hash algorithm as specified in Table 13 for the signature data digest. Signatures using other hash algorithms MUST be considered invalid.¶
An implementation supporting a specific MLDSA + ECC algorithm MUST also support the matching hash algorithm.¶
Algorithm ID reference  Hash function  Hash function ID reference 

35, 37, 39  SHA3256  12 
36, 38, 40  SHA3512  14 
6.2.2. Key generation procedure
The implementation MUST independently generate the MLDSA and the ECC component keys. MLDSA key generation follows the specification [FIPS204] and the artifacts are encoded as fixedlength octet strings as defined in Section 6.1.3. For ECC this is done following the relative specification in [RFC7748], [SP800186], or [RFC5639], and encoding the artifacts as specified in Section 6.1.1 or Section 6.1.2 as fixedlength octet strings.¶
6.2.3. Signature Generation
To sign a message M
with MLDSA + EdDSA the following sequence of
operations has to be performed:¶

Generate
dataDigest
according to [ID.ietfopenpgpcryptorefresh] Section 5.2.4¶ 
Create the EdDSA signature over
dataDigest
withEdDSA.Sign()
from Section 6.1.1¶ 
Create the MLDSA signature over
dataDigest
withMLDSA.Sign()
from Section 6.1.3¶ 
Encode the EdDSA and MLDSA signatures according to the packet structure given in Section 6.3.1.¶
To sign a message M
with MLDSA + ECDSA the following sequence of
operations has to be performed:¶

Generate
dataDigest
according to [ID.ietfopenpgpcryptorefresh] Section 5.2.4¶ 
Create the ECDSA signature over
dataDigest
withECDSA.Sign()
from Section 6.1.2¶ 
Create the MLDSA signature over
dataDigest
withMLDSA.Sign()
from Section 6.1.3¶ 
Encode the ECDSA and MLDSA signatures according to the packet structure given in Section 6.3.1.¶
6.2.4. Signature Verification
To verify a MLDSA + EdDSA signature the following sequence of operations has to be performed:¶

Verify the EdDSA signature with
EdDSA.Verify()
from Section 6.1.1¶ 
Verify the MLDSA signature with
MLDSA.Verify()
from Section 6.1.3¶
To verify a MLDSA + ECDSA signature the following sequence of operations has to be performed:¶

Verify the ECDSA signature with
ECDSA.Verify()
from Section 6.1.2¶ 
Verify the MLDSA signature with
MLDSA.Verify()
from Section 6.1.3¶
As specified in Section 4.3 an implementation MUST validate both signatures, i.e. EdDSA/ECDSA and MLDSA, to state that a composite MLDSA + ECC signature is valid.¶
6.3. Packet Specifications
6.3.1. Signature Packet (Tag 2)
The composite MLDSA + ECC schemes MUST be used only with v6 signatures, as defined in [ID.ietfopenpgpcryptorefresh].¶
The algorithmspecific v6 signature parameters for MLDSA + EdDSA signatures consists of:¶

A fixedlength octet string representing the EdDSA signature, whose length depends on the algorithm ID as specified in Table 10.¶

A fixedlength octet string of the MLDSA signature value, whose length depends on the algorithm ID as specified in Table 12.¶
The algorithmspecific v6 signature parameters for MLDSA + ECDSA signatures consists of:¶

A fixedlength octet string of the bigendian encoded ECDSA value
R
, whose length depends on the algorithm ID as specified in Table 11.¶ 
A fixedlength octet string of the bigendian encoded ECDSA value
S
, whose length depends on the algorithm ID as specified in Table 11.¶ 
A fixedlength octet string of the MLDSA signature value, whose length depends on the algorithm ID as specified in Table 12.¶
6.3.2. Key Material Packets
The composite MLDSA + ECC schemes MUST be used only with v6 keys, as defined in [ID.ietfopenpgpcryptorefresh].¶
The algorithmspecific public key for MLDSA + EdDSA keys is this series of values:¶

A fixedlength octet string representing the EdDSA public key, whose length depends on the algorithm ID as specified in Table 10.¶

A fixedlength octet string containing the MLDSA public key, whose length depends on the algorithm ID as specified in Table 12.¶
The algorithmspecific secret key for MLDSA + EdDSA keys is this series of values:¶

A fixedlength octet string representing the EdDSA secret key, whose length depends on the algorithm ID as specified in Table 10.¶

A fixedlength octet string containing the MLDSA secret key, whose length depends on the algorithm ID as specified in Table 12.¶
The algorithmspecific public key for MLDSA + ECDSA keys is this series of values:¶

A fixedlength octet string representing the ECDSA public key in SEC1 format, as specified in section Section 2.1.1 and with length specified in Table 11.¶

A fixedlength octet string containing the MLDSA public key, whose length depends on the algorithm ID as specified in Table 12.¶
The algorithmspecific secret key for MLDSA + ECDSA keys is this series of values:¶
7. SLHDSA
7.1. The SLHDSA Algorithms
The following table describes the SLHDSA parameters and artifact lengths:¶
Parameter ID reference  Parameter name suffix  SLHDSA public key  SLHDSA secret key  SLHDSA signature 

1  128s  32  64  7856 
2  128f  32  64  17088 
3  192s  48  96  16224 
4  192f  48  96  35664 
5  256s  64  128  29792 
6  256f  64  128  49856 
7.1.1. Signature Data Digest
Signature data (i.e. the data to be signed) is digested prior to signing operations, see [ID.ietfopenpgpcryptorefresh] Section 5.2.4. SLHDSA signatures MUST use the associated hash algorithm as specified in Table 15 for the signature data digest. Signatures using other hash algorithms MUST be considered invalid.¶
An implementation supporting a specific SLHDSA algorithm and parameter MUST also support the matching hash algorithm.¶
Algorithm ID reference  Parameter ID reference  Hash function  Hash function ID reference 

41  1, 2  SHA256  8 
41  3, 4, 5, 6  SHA512  10 
42  1, 2  SHA3256  12 
42  3, 4, 5, 6  SHA3512  14 
7.1.2. Key generation
SLHDSA key generation is performed via the algorithm SLHDSA.KeyGen
as
specified in [FIPS205], and the artifacts are encoded as fixedlength octet
strings as defined in Section 7.1.¶
7.1.3. Signature Generation
SLHDSA signature generation is performed via the algorithm SLHDSA.Sign
as
specified in [FIPS205]. The variable opt_rand
is set to PK.seed
. See
also Section 9.4.¶
An implementation MUST set the Parameter ID in the signature equal to the issuing secret key Parameter ID.¶
7.1.4. Signature Verification
SLHDSA signature verification is performed via the algorithm SLHDSA.Verify
as specified in [FIPS205].¶
An implementation MUST check that the Parameter ID in the signature and in the key match when verifying.¶
7.2. Packet specifications
7.2.1. Signature Packet (Tag 2)
The SLHDSA scheme MUST be used only with v6 signatures, as defined in [ID.ietfopenpgpcryptorefresh] Section 5.2.3.¶
The algorithmspecific v6 Signature parameters consists of:¶
7.2.2. Key Material Packets
The SLHDSA scheme MUST be used only with v6 keys, as defined in [ID.ietfopenpgpcryptorefresh].¶
The algorithmspecific public key is this series of values:¶

A oneoctet value specifying the SLHDSA parameter ID defined in Table 3 and Table 4. The values
0x00
and0xFF
are reserved for future extensions.¶ 
A fixedlength octet string containing the SLHDSA public key, whose length depends on the parameter ID as specified in Table 14.¶
The algorithmspecific secret key is this value:¶
8. Migration Considerations
The postquantum KEM algorithms defined in Table 1 and the signature algorithms defined in Table 2 are a set of new public key algorithms that extend the algorithm selection of [ID.ietfopenpgpcryptorefresh]. During the transition period, the postquantum algorithms will not be supported by all clients. Therefore various migration considerations must be taken into account, in particular backwards compatibility to existing implementations that have not yet been updated to support the postquantum algorithms.¶
8.1. Key preference
Implementations SHOULD prefer PQ(/T) keys when multiple options are available.¶
For instance, if encrypting for a recipient for which both a valid PQ/T and a valid ECC certificate are available, the implementation SHOULD choose the PQ/T certificate. In case a certificate has both a PQ/T and an ECC encryptioncapable valid subkey, the PQ/T subkey SHOULD be preferred.¶
An implementation MAY sign with both a PQ(/T) and an ECC key using multiple signatures over the same data as described in Section 4.4. Signing only with PQ(/T) key material is not backwards compatible.¶
Note that the confidentiality of a message is not postquantum secure when encrypting to multiple recipients if at least one recipient does not support PQ/T encryption schemes. An implementation SHOULD NOT abort the encryption process in this case to allow for a smooth transition to postquantum cryptography.¶
8.2. Key generation strategies
It is REQUIRED to generate fresh secrets when generating PQ(/T) keys. Reusing key material from existing ECC keys in PQ(/T) keys does not provide backwards compatibility, and the fingerprint will differ.¶
An OpenPGP (v6) certificate is composed of a certificationcapable primary key and one or more subkeys for signature, encryption, and authentication. Two migration strategies are recommended:¶

Generate two independent certificates, one for PQ(/T)capable implementations, and one for legacy implementations. Implementations not understanding PQ(/T) certificates can use the legacy certificate, while PQ(/T)capable implementations will prefer the newer certificate. This allows having an older v4 or v6 ECC certificate for compatibility and a v6 PQ(/T) certificate, at a greater complexity in key distribution.¶

Attach PQ(/T) encryption and signature subkeys to an existing v6 ECC certificate. Implementations understanding PQ(/T) will be able to parse and use the subkeys, while PQ(/T)incapable implementations can gracefully ignore them. This simplifies key distribution, as only one certificate needs to be communicated and verified, but leaves the primary key vulnerable to quantum computer attacks.¶
9. Security Considerations
9.1. Hashing in ECCKEM
Our construction of the ECCKEMs, in particular the inclusion of
eccCipherText
in the final hashing step in encapsulation and decapsulation
that produces the eccKeyShare
, is standard and known as hashed ElGamal key
encapsulation, a hashed variant of ElGamal encryption. It ensures INDCCA2
security in the random oracle model under some DiffieHellman intractability
assumptions [CS03]. The additional inclusion of eccPublicKey
follows the
security advice in Section 6.1 of [RFC7748].¶
9.2. Key combiner
For the key combination in Section 5.2.2 this specification limits itself to the use of KMAC. The sponge construction used by KMAC was proven to be indifferentiable from a random oracle [BDPA08]. This means, that in contrast to SHA2, which uses a MerkleDamgard construction, no HMACbased construction is required for key combination. Except for a domain separation it is sufficient to simply process the concatenation of any number of key shares when using a spongebased construction like KMAC. The construction using KMAC ensures a standardized domain separation. In this case, the processed message is then the concatenation of any number of key shares.¶
More precisely, for a given capacity c
the indifferentiability proof shows
that assuming there are no weaknesses found in the Keccak permutation, an
attacker has to make an expected number of 2^(c/2)
calls to the permutation
to tell KMAC from a random oracle. For a random oracle, a difference in only a
single bit gives an unrelated, uniformly random output. Hence, to be able to
distinguish a key K
, derived from shared keys K1
and K2
(and ciphertexts
C1
and C2
) as¶
K = KMAC(domainSeparation, counter  K1  C1  K2  C2  fixedInfo, outputBits, customization)¶
from a random bit string, an adversary has to know (or correctly guess) both
key shares K1
and K2
, entirely.¶
The proposed construction in Section 5.2.2 preserves INDCCA2 of any of its ingredient KEMs, i.e. the newly formed combined KEM is INDCCA2 secure as long as at least one of the ingredient KEMs is. Indeed, the above stated indifferentiability from a random oracle qualifies Keccak as a splitkey pseudorandom function as defined in [GHP18]. That is, Keccak behaves like a random function if at least one input shared secret is picked uniformly at random. Our construction can thus be seen as an instantiation of the INDCCA2 preserving Example 3 in Figure 1 of [GHP18], up to some reordering of input shared secrets and ciphertexts. In the random oracle setting, the reordering does not influence the arguments in [GHP18].¶
9.3. Domain separation and binding
The domSeparation
information defined in Section 5.2.2 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 or
context.¶
The fixedInfo
defined in Section 5.2.1 binds the derived KEK to the
chosen algorithm and communication parties. The algorithm ID identifies
univocally the algorithm, the parameters for its instantiation, and the length
of all artifacts, including the derived key.¶
This is in line with the Recommendation for ECC in section 5.5 of [SP80056A]. Other fields included in the recommendation are not relevant for the OpenPGP protocol, since the sender is not required to have a key of their own, there are no preshared secrets, and all the other parameters are univocally defined by the algorithm ID.¶
Furthermore, we do not require the recipients public key into the key combiner as the public key material is already included in the component key derivation functions. Given two KEMs which we assume to be multiuser secure, we combine their outputs using a KEMcombiner:¶
K = H(K1, C1, K2, C2), C = (C1, C2)¶
Our aim is to preserve multiuser security. A common approach to this is to add the public key into the key derivation for K. However, it turns out that this is not necessary here. To break security of the combined scheme in the multiuser setting, the adversary has to distinguish a set of challenge keys¶
K_u = H(K1_u, C1_u, K2_u, C2*_u)¶
for users u in some set from random, also given ciphertexts C*_u = (C1*_u,
C2*_u)
. For each of these K* it holds that if the adversary never makes a
query¶
H(K1*_u, C1*_u, K2*_u, C2*_u)¶
they have a zero advantage over guessing.¶
The only multiuser advantage that the adversary could gain therefore consists of queries to H that are meaningful for two different users u1 != u2 and their associated public keys. This is only the case if¶
(c1*_u1, c2*_u1) = (c1*_u2, c2*_u2)¶
as the ciphertext values decide for which challenge the query is meaningful. This means that a ciphertext collision is needed between challenges. Assuming that the randomness used in the generation of the two challenges is uncorrelated, this is negligible.¶
In consequence, the ciphertexts already work sufficiently well as domainseparator.¶
9.4. SLHDSA Message Randomizer
The specification of SLHDSA [FIPS205] prescribes an optional nondeterministic message randomizer. This is not used in this specification, as OpenPGP v6 signatures already provide a salted signature data digest of the appropriate size.¶
9.5. Binding hashes in signatures with signature algorithms
In order not to extend the attack surface, we bind the hash algorithm used for signature data digestion to the hash algorithm used internally by the signature algorithm.¶
MLDSA internally uses a SHAKE256 digest, therefore we require SHA3 in the MLDSA + ECC signature packet, see Section 6.2.1. Note that we bind a NIST security category 2 hash function to a signature algorithm that falls into NIST security category 3. This does not constitute a security bottleneck: because of the unpredictable random salt that is prepended to the digested data in v6 signatures, the hardness assumption is not collision resistance but secondpreimage resistance.¶
In the case of SLHDSA the internal hash algorithm varies based on the algorithm and parameter ID, see Section 7.1.1.¶
10. Additional considerations
10.1. Performance Considerations for SLHDSA
This specification introduces both MLDSA + ECC as well as SLHDSA as PQ(/T) signature schemes.¶
Generally, it can be said that MLDSA + ECC 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, MLDSA has far greater requirements than traditional schemes like ECbased or even RSA signature schemes. Implementers may want to offer SLHDSA for applications where a higher degree of trust in the signature scheme is required. However, SLHDSA 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 MLDSA + ECC signature schemes.¶
Pertaining to the execution time, the particularly costly operation in SLHDSA is the signature generation. In order to achieve short signature generation times, one of the parameter sets with the name ending in the letter "f" for "fast" should be chosen. This comes at the expense of a larger signature size.¶
In order to minimize the space requirements of a SLHDSA signature, a parameter set ending in "s" for "small" should be chosen. This comes at the expense of a longer signature generation time.¶
11. IANA Considerations
IANA will add the following registries to the Pretty Good Privacy (PGP)
registry group at https://www.iana.org/assignments/pgpparameters:¶

Registry name:
SLHDSASHA2 parameters
¶ 
Registry name:
SLHDSASHAKE parameters
¶
Furthermore IANA will add the algorithm IDs defined in Table 1 and
Table 2 to the registry Public Key Algorithms
.¶
12. Changelog
12.1. draftwussleropenpgppqc01

Shifted the algorithm IDs by 4 to align with the cryptorefresh.¶

Renamed v5 packets into v6 to align with the cryptorefresh.¶

Defined INDCCA2 security for KDF and key combination.¶

Added explicit key generation procedures.¶

Changed the key combination KMAC salt.¶

Mandated Parameter ID check in SPHINCS+ signature verification.¶

Fixed key share size for Kyber768.¶

Added "Preliminaries" section.¶

Fixed IANA considerations.¶
13. Contributors
Stephan Ehlen (BSI)
CarlDaniel Hailfinger (BSI)
Andreas Huelsing (TU Eindhoven)
Johannes Roth (MTG AG)¶
14. References
14.1. Normative References
 [ID.ietfopenpgpcryptorefresh]
 Wouters, P., Huigens, D., Winter, J., and N. Yutaka, "OpenPGP", Work in Progress, InternetDraft, draftietfopenpgpcryptorefresh13, , <https://datatracker.ietf.org/doc/html/draftietfopenpgpcryptorefresh13>.
 [RFC3394]
 Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, , <https://www.rfceditor.org/rfc/rfc3394>.
 [RFC7748]
 Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, , <https://www.rfceditor.org/rfc/rfc7748>.
 [RFC8032]
 Josefsson, S. and I. Liusvaara, "EdwardsCurve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, , <https://www.rfceditor.org/rfc/rfc8032>.
 [RFC8126]
 Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfceditor.org/rfc/rfc8126>.
14.2. Informative References
 [BDPA08]
 Bertoni, G., Daemen, J., Peters, M., and G. Assche, "On the Indifferentiability of the Sponge Construction", , <https://doi.org/10.1007/9783540789673_11>.
 [CS03]
 Cramer, R. and V. Shoup, "Design and Analysis of Practical PublicKey Encryption Schemes Secure against Adaptive Chosen Ciphertext Attack", , <https://doi.org/10.1137/S0097539702403773>.
 [draftdriscollpqthybridterminology]
 Driscoll, F., "Terminology for PostQuantum Traditional Hybrid Schemes", , <https://datatracker.ietf.org/doc/html/draftdriscollpqthybridterminology>.
 [FIPS203]
 National Institute of Standards and Technology, "ModuleLatticeBased KeyEncapsulation Mechanism Standard", , <https://doi.org/10.6028/NIST.FIPS.203.ipd>.
 [FIPS204]
 National Institute of Standards and Technology, "ModuleLatticeBased Digital Signature Standard", , <https://doi.org/10.6028/NIST.FIPS.204.ipd>.
 [FIPS205]
 National Institute of Standards and Technology, "Stateless HashBased Digital Signature Standard", , <https://doi.org/10.6028/NIST.FIPS.205.ipd>.
 [GHP18]
 Giacon, F., Heuer, F., and B. Poettering, "KEM Combiners", , <https://doi.org/10.1007/9783319765785_7>.
 [NISTPQC]
 Chen, L., Moody, D., and Y. Liu, "PostQuantum Cryptography Standardization", , <https://csrc.nist.gov/projects/postquantumcryptography/postquantumcryptographystandardization>.
 [NISTIR8413]
 Alagic, G., Apon, D., Cooper, D., Dang, Q., Dang, T., Kelsey, J., Lichtinger, J., Miller, C., Moody, D., Peralta, R., Perlner, R., Robinson, A., SmithTone, D., and Y. Liu, "Status Report on the Third Round of the NIST PostQuantum Cryptography Standardization Process", NIST IR 8413 , , <https://doi.org/10.6028/NIST.IR.8413upd1>.
 [RFC5639]
 Lochter, M. and J. Merkle, "Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation", RFC 5639, DOI 10.17487/RFC5639, , <https://www.rfceditor.org/rfc/rfc5639>.
 [SEC1]
 Standards for Efficient Cryptography Group, "Standards for Efficient Cryptography 1 (SEC 1)", , <https://secg.org/sec1v2.pdf>.
 [SP800185]
 Kelsey, J., Chang, S., and R. Perlner, "SHA3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash", NIST Special Publication 800185 , , <https://doi.org/10.6028/NIST.SP.800185>.
 [SP800186]
 Chen, L., Moody, D., Regenscheid, A., and K. Randall, "Recommendations for Discrete LogarithmBased Cryptography: Elliptic Curve Domain Parameters", NIST Special Publication 800186 , , <https://doi.org/10.6028/NIST.SP.800186>.
 [SP80056A]
 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for PairWise KeyEstablishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 80056A Rev. 3 , , <https://doi.org/10.6028/NIST.SP.80056Ar3>.
 [SP80056C]
 Barker, E., Chen, L., and R. Davis, "Recommendation for KeyDerivation Methods in KeyEstablishment Schemes", NIST Special Publication 80056C Rev. 2 , , <https://doi.org/10.6028/NIST.SP.80056Cr2>.
Acknowledgments
Thanks to Daniel Huigens and Evangelos Karatsiolis for the early review and feedback on this document.¶