HQC-KEM Key Agreement for TLS 1.3

Internet-Draft	HQC-KEM for TLS 1.3	October 2026
Preuß Mattsson & Ruohomaa	Expires 12 April 2027	[Page]

Abstract

This document defines nine quantum-resistant TLS 1.3 key exchange algorithms based on HQC-KEM, the code-based KEM selected by NIST for standardization in forthcoming FIPS 207. Three use HQC-KEM standalone, two combine it with X25519 or X448 in PQ/T hybrids, two combine it with ML-KEM in PQ/PQ hybrids, and two combine it with ML-KEM and X25519 or X448 in PQ/PQ/T hybrids. Because HQC-KEM relies on hardness assumptions and constructions different from those underlying lattice-based ML-KEM, these algorithms provide algorithmic diversity that can mitigate the impact of future cryptanalytic advances or implementation weaknesses in lattice-based cryptography. The algorithms are intended for TLS 1.3, DTLS 1.3, and QUIC, and the hybrid algorithms follow the general hybrid key exchange construction defined for TLS 1.3.¶

1. Introduction

The transition to post-quantum cryptography requires new key exchange mechanisms for TLS 1.3 [RFC9846]. ML-KEM [FIPS203] is the primary post-quantum KEM and is used in TLS 1.3 both standalone [I-D.ietf-tls-mlkem] and in hybrid key exchange algorithms such as X25519MLKEM768 [RFC10024]. ML-KEM is lattice-based, and its security relies on the hardness of the Module Learning With Errors (MLWE) problem.¶

In March 2025, NIST selected HQC (Hamming Quasi-Cyclic) for standardization as a second post-quantum KEM [NISTIR8545]. HQC-KEM is code-based, and its security relies on the hardness of decoding random quasi-cyclic codes. NIST selected HQC to provide a backup to ML-KEM that is based on a different hardness assumption and construction, so that a future cryptanalytic breakthrough against lattice-based cryptography or ML-KEM does not leave deployments without a standardized post-quantum KEM. NIST is specifying HQC-KEM in the forthcoming [FIPS207]. HQC-KEM has larger public keys and ciphertexts and is slower than ML-KEM [PQ-PQ].¶

Editor's note: At the time of writing, FIPS 207 has not been published, not even as an Initial Public Draft. This document is based on the HQC specification of 2025-08-22 [HQC]. All references to [FIPS207], including section references, parameter set names, and the sizes in Section 3.1, need to be verified and updated once FIPS 207 is published. This note is to be removed before publication as an RFC.¶

[RFC9954] specifies a general design for hybrid key exchange in TLS 1.3. This document applies that design to six hybrid key exchange algorithms and separately defines three standalone key exchange algorithms based on HQC-KEM.¶

HQCKEM128, HQCKEM192, and HQCKEM256 use the HQC-KEM parameter sets targeting security categories 1, 3, and 5 [SP800-57], respectively, without any other component. They provide security against quantum attackers as long as HQC-KEM remains secure.¶
HQCKEM192X25519 and HQCKEM256X448 are PQ/T hybrids [RFC9794] that combine HQC-KEM with the traditional elliptic-curve algorithms X25519 and X448 [RFC7748]. They provide security against quantum attackers as long as HQC-KEM remains secure and security against classical attackers as long as at least one of the two components remains secure.¶
HQCKEM192MLKEM768 and HQCKEM256MLKEM1024 are PQ/PQ hybrids [RFC9794] that combine HQC-KEM with ML-KEM [FIPS203]. They provide security against quantum attackers as long as at least one of the code-based and lattice-based components remains secure, mitigating the impact of future cryptanalytic advances or implementation weaknesses against either component.¶
HQCKEM192MLKEM768X25519 and HQCKEM256MLKEM1024X448 are PQ/PQ/T hybrids that combine HQC-KEM with both ML-KEM and X25519 or X448, respectively. They provide security against quantum attackers as long as at least one of the post-quantum components remains secure, and security against classical attackers as long as at least one of the three components remains secure.¶

Recent developments have increased interest in algorithmic diversity and conservative key exchange designs. In particular, a claimed polynomial-time quantum algorithm for the Dihedral Coset Problem (DCP) [Simon26], which was subsequently challenged [GRZ26], prompted discussion about the security of lattice-based cryptography, while recent advances in the cryptanalysis of Goppa codes have challenged long-standing assumptions and led BSI to no longer recommend Classic McEliece [ISO18033-2-AMD2] for new developments [BSI]. The algorithms specified in this document provide algorithmic diversity, while the PQ/PQ and PQ/PQ/T hybrids provide a conservative design, with significantly smaller key shares and better performance [PQ-PQ] than FrodoKEM [ISO18033-2-AMD2]. These hybrids are particularly well suited to high-security applications where handshake latency is not a primary concern.¶

The algorithms defined in this document are intended for use with TLS 1.3 [RFC9846], DTLS 1.3 [RFC9147], and QUIC [RFC9001]. The hybrid algorithms follow the hybrid key exchange construction defined in [RFC9954], which for the PQ/PQ/T hybrids is applied with three components. This document defines only additional TLS NamedGroup values and their associated key share and shared secret encodings. It does not modify the TLS 1.3 handshake, key schedule, or negotiation mechanisms.¶

3. HQC-KEM Key Exchange Algorithms

This document defines nine TLS NamedGroups for use with the TLS 1.3 supported_groups and key_share extensions. For the hybrid algorithms, key shares and shared secrets are encoded by concatenating the component values in the order indicated by the name. All encodings are fixed-length.¶

For all algorithms, the client key_exchange value contains the encapsulation key or public key of each component, and the server key_exchange value contains the ciphertext or public key of each component. The KEM shared secrets are produced by encapsulation and decapsulation as specified in [FIPS207] and [FIPS203]. X25519 and X448 shared secrets are produced as specified in Section 7.4.2 of [RFC9846]. The resulting asymmetric shared secret is the input to the TLS 1.3 key schedule Section 7.1 of [RFC9846].¶

3.1. Sizes

Table 1 summarizes the security category and the sizes in bytes of the client key share, the server key share, and the shared secret for each algorithm.¶

Table 1: Security categories and key share and shared secret sizes in bytes
NamedGroup	Security category	Client share	Server share	Shared secret
HQCKEM128	1	2241	4433	32
HQCKEM192	3	4514	8978	32
HQCKEM256	5	7237	14421	32
HQCKEM192X25519	3	4546	9010	64
HQCKEM256X448	5	7293	14477	88
HQCKEM192MLKEM768	3	5698	10066	64
HQCKEM256MLKEM1024	5	8805	15989	64
HQCKEM192MLKEM768X25519	3	5730	10098	96
HQCKEM256MLKEM1024X448	5	8861	16045	120

All key share sizes are well below the maximum key_exchange length of 2¹⁶ - 1 bytes.¶

3.2. HQCKEM128, HQCKEM192, and HQCKEM256

For HQCKEM128, HQCKEM192, and HQCKEM256, the client key_exchange value contains the HQC-KEM-128, HQC-KEM-192, or HQC-KEM-256 encapsulation key, respectively:¶

struct {
    opaque hqckem_key[2241];
} HQCKEM128ClientShare;

struct {
    opaque hqckem_key[4514];
} HQCKEM192ClientShare;

struct {
    opaque hqckem_key[7237];
} HQCKEM256ClientShare;

The server key_exchange value contains the HQC-KEM ciphertext:¶

struct {
    opaque hqckem_ciphertext[4433];
} HQCKEM128ServerShare;

struct {
    opaque hqckem_ciphertext[8978];
} HQCKEM192ServerShare;

struct {
    opaque hqckem_ciphertext[14421];
} HQCKEM256ServerShare;

The 32-byte shared secret input to the TLS 1.3 key schedule is the HQC-KEM shared secret.¶

3.3. HQCKEM192X25519

For HQCKEM192X25519, the client key_exchange value contains the HQC-KEM-192 encapsulation key followed by the X25519 public key:¶

struct {
    opaque hqckem_key[4514];
    opaque ecdhe_key[32];
} HQCKEM192X25519ClientShare;

The server key_exchange value contains the HQC-KEM-192 ciphertext followed by the X25519 public key:¶

struct {
    opaque hqckem_ciphertext[8978];
    opaque ecdhe_key[32];
} HQCKEM192X25519ServerShare;

The 64-byte shared secret input to the TLS 1.3 key schedule is the concatenation of the HQC-KEM shared secret followed by the X25519 shared secret:¶

concatenated_shared_secret =
    HQCKEM192_shared_secret || X25519_shared_secret

3.4. HQCKEM256X448

For HQCKEM256X448, the client key_exchange value contains the HQC-KEM-256 encapsulation key followed by the X448 public key:¶

struct {
    opaque hqckem_key[7237];
    opaque ecdhe_key[56];
} HQCKEM256X448ClientShare;

The server key_exchange value contains the HQC-KEM-256 ciphertext followed by the X448 public key:¶

struct {
    opaque hqckem_ciphertext[14421];
    opaque ecdhe_key[56];
} HQCKEM256X448ServerShare;

The 88-byte shared secret input to the TLS 1.3 key schedule is the concatenation of the HQC-KEM shared secret followed by the X448 shared secret:¶

concatenated_shared_secret =
    HQCKEM256_shared_secret || X448_shared_secret

3.5. HQCKEM192MLKEM768

For HQCKEM192MLKEM768, the client key_exchange value contains the HQC-KEM-192 encapsulation key followed by the ML-KEM-768 encapsulation key:¶

struct {
    opaque hqckem_key[4514];
    opaque mlkem_key[1184];
} HQCKEM192MLKEM768ClientShare;

The server key_exchange value contains the HQC-KEM-192 ciphertext followed by the ML-KEM-768 ciphertext:¶

struct {
    opaque hqckem_ciphertext[8978];
    opaque mlkem_ciphertext[1088];
} HQCKEM192MLKEM768ServerShare;

The 64-byte shared secret input to the TLS 1.3 key schedule is the concatenation of the HQC-KEM shared secret followed by the ML-KEM shared secret:¶

concatenated_shared_secret =
    HQCKEM192_shared_secret || MLKEM768_shared_secret

3.6. HQCKEM256MLKEM1024

For HQCKEM256MLKEM1024, the client key_exchange value contains the HQC-KEM-256 encapsulation key followed by the ML-KEM-1024 encapsulation key:¶

struct {
    opaque hqckem_key[7237];
    opaque mlkem_key[1568];
} HQCKEM256MLKEM1024ClientShare;

The server key_exchange value contains the HQC-KEM-256 ciphertext followed by the ML-KEM-1024 ciphertext:¶

struct {
    opaque hqckem_ciphertext[14421];
    opaque mlkem_ciphertext[1568];
} HQCKEM256MLKEM1024ServerShare;

The 64-byte shared secret input to the TLS 1.3 key schedule is the concatenation of the HQC-KEM shared secret followed by the ML-KEM shared secret:¶

concatenated_shared_secret =
    HQCKEM256_shared_secret || MLKEM1024_shared_secret

3.7. HQCKEM192MLKEM768X25519

For HQCKEM192MLKEM768X25519, the client key_exchange value contains the HQC-KEM-192 encapsulation key, followed by the ML-KEM-768 encapsulation key, followed by the X25519 public key:¶

struct {
    opaque hqckem_key[4514];
    opaque mlkem_key[1184];
    opaque ecdhe_key[32];
} HQCKEM192MLKEM768X25519ClientShare;

The server key_exchange value contains the HQC-KEM-192 ciphertext, followed by the ML-KEM-768 ciphertext, followed by the X25519 public key:¶

struct {
    opaque hqckem_ciphertext[8978];
    opaque mlkem_ciphertext[1088];
    opaque ecdhe_key[32];
} HQCKEM192MLKEM768X25519ServerShare;

The 96-byte shared secret input to the TLS 1.3 key schedule is the concatenation of the HQC-KEM shared secret, followed by the ML-KEM shared secret, followed by the X25519 shared secret:¶

concatenated_shared_secret =
    HQCKEM192_shared_secret || MLKEM768_shared_secret ||
    X25519_shared_secret

3.8. HQCKEM256MLKEM1024X448

For HQCKEM256MLKEM1024X448, the client key_exchange value contains the HQC-KEM-256 encapsulation key, followed by the ML-KEM-1024 encapsulation key, followed by the X448 public key:¶

struct {
    opaque hqckem_key[7237];
    opaque mlkem_key[1568];
    opaque ecdhe_key[56];
} HQCKEM256MLKEM1024X448ClientShare;

The server key_exchange value contains the HQC-KEM-256 ciphertext, followed by the ML-KEM-1024 ciphertext, followed by the X448 public key:¶

struct {
    opaque hqckem_ciphertext[14421];
    opaque mlkem_ciphertext[1568];
    opaque ecdhe_key[56];
} HQCKEM256MLKEM1024X448ServerShare;

The 120-byte shared secret input to the TLS 1.3 key schedule is the concatenation of the HQC-KEM shared secret, followed by the ML-KEM shared secret, followed by the X448 shared secret:¶

concatenated_shared_secret =
    HQCKEM256_shared_secret || MLKEM1024_shared_secret ||
    X448_shared_secret

3.9. Validation

Both client and server MUST check that the received key share has the length given in Table 1 for the negotiated group and abort with an "illegal_parameter" alert if it fails.¶

The server MUST perform any encapsulation key checks specified in [FIPS207] on the client's HQC-KEM encapsulation key and abort with an "illegal_parameter" alert if they fail. For algorithms with an ML-KEM component, the server MUST also perform the encapsulation key check described in Section 7.2 of [FIPS203] on the client's ML-KEM encapsulation key and abort with an "illegal_parameter" alert if it fails.¶

Editor's note: Add a section reference to the HQC-KEM input checks in [FIPS207], if any are specified.¶

If HQC-KEM or ML-KEM decapsulation fails for any reason, the client MUST abort with an "internal_error" alert.¶

For algorithms with an X25519 or X448 component, both client and server MUST calculate the X25519 or X448 part of the shared secret as described in Section 7.4.2 of [RFC9846], including the all-zero shared secret check, and abort with an "illegal_parameter" alert if it fails.¶

4. Security Considerations

The hybrid algorithms defined in this document use the hybrid construction specified in [RFC9954]. Their security relies on the TLS 1.3 transcript binding and key schedule. The security considerations in [RFC9846], [FIPS207], [FIPS203], [SP800-227], [RFC7748], and [RFC9954] apply to the algorithms defined in this document. A key share, or any of its components, MUST NOT be reused for multiple connections, as required by TLS 1.3 [RFC9846].¶

HQC-KEM-128, HQC-KEM-192, and HQC-KEM-256 target post-quantum security categories 1, 3, and 5 [SP800-57], respectively. All algorithms with HQC-KEM-256 provide security category 5, matching the security level of cipher suites with AES-256 and ChaCha20.¶

HQC-KEM is designed to provide indistinguishability under adaptive chosen-ciphertext attack (IND-CCA2) security [HQC]. The security of HQC-KEM relies on the hardness of decoding random quasi-cyclic codes, which is a different assumption than the module lattice assumptions underlying ML-KEM. HQC-KEM therefore provides algorithmic diversity for deployments concerned about future cryptanalytic advances against lattice-based cryptography, see Section 4.1. Hybrid constructions also protect against implementation vulnerabilities, such as side-channel leakage or software bugs, in one of the component algorithms.¶

Compared with X25519MLKEM768 [RFC10024], which has the value Y in the Recommended column of the IANA TLS Supported Groups registry [IANA], HQCKEM192MLKEM768X25519 and HQCKEM256MLKEM1024X448 provide greater security margin and algorithmic diversity, at the cost of larger messages and higher computational cost. The key share sizes and the computational cost are dominated by the HQC-KEM component.¶

The hybrid key exchange algorithms defined in this document are compatible with the key combiner specified in [SP800-227] and the CatKDF key combiner specified in [ETSI-TS-103-744]. The security analysis of [RFC9954] applies recursively, and the PQ/PQ/T hybrids retain the security of their strongest component.¶

A fundamental requirement of hybrid constructions is that their security is at least as high as that of their strongest component; that is, the construction preserves the cryptographic security properties of its components [EU25], [EU26], [NCSC26], [SP800-227]. The hybrid key exchange algorithms defined in this document are designed to meet this requirement and preserve the quantum resistance and IND-CCA2 security of HQC-KEM and ML-KEM. X25519 provides approximately 128 bits of classical security and X448 approximately 224 bits of classical security [RFC7748]; neither provides quantum resistance. Compared with P-curves offering a comparable security level, X25519 and X448 are significantly faster and provides greater implementation robustness.¶

Deployments that require a traditional component in the key exchange, for example due to regulatory recommendations for PQ/T hybrids, should use HQCKEM192X25519, HQCKEM256X448, HQCKEM192MLKEM768X25519, or HQCKEM256MLKEM1024X448 rather than the PQ/PQ hybrids or the standalone algorithms. HQCKEM192MLKEM768X25519 and HQCKEM256MLKEM1024X448 combine the algorithmic diversity of the PQ/PQ hybrids with a traditional component.¶

Availability is a fundamental security property and part of the CIA triad in information security [SP800-12]. HQC-KEM encapsulation keys and ciphertexts are significantly larger than those of ML-KEM at the same security category. Large client key shares are known to cause interoperability problems with non-compliant or buggy legacy TLS implementations, as well as with middleboxes and other network infrastructure that impose non-compliant limitations on large TLS ClientHello messages. Large key shares also increase bandwidth, memory, and computational costs for constrained endpoints or deployments operating over lossy or bandwidth-constrained networks, potentially reducing availability. Clients may choose to advertise the groups in this document in the supported_groups extension without sending a corresponding key share in the initial ClientHello, at the cost of an additional round trip if the server selects one of them using HelloRetryRequest.¶

An HQC-KEM ciphertext is roughly twice the size of the encapsulation key, making the server’s first flight much larger than the ClientHello. Each transport typically pays one extra round trip for this. In QUIC, the anti-amplification limit can delay the server’s first flight until the client’s address is validated. DTLS 1.3 servers SHOULD verify return routability with a HelloRetryRequest cookie (Section 5.1 of [RFC9147]) before sending an HQC-KEM ciphertext when the client's address has not otherwise been validated.¶

Implementations MUST NOT use the algorithms defined in this document with TLS 1.2 or DTLS 1.2, which are obsolete and should be phased out as soon as possible. 3GPP already mandates that TLS 1.2 be disabled by default.¶

4.1. Algorithmic Diversity

One risk to consider is a novel algorithm that breaks most of lattice-based cryptography, regardless of whether the underlying lattices are structured, as in ML-KEM [FIPS203], or unstructured, as in FrodoKEM [ISO18033-2-AMD2]. For example, a polynomial-time quantum algorithm for the Dihedral Coset Problem (DCP) would, by Regev’s reduction [Regev04], yield a polynomial-time quantum algorithm for the Learning With Errors (LWE) problem. The best known quantum algorithm for DCP is Kuperberg’s subexponential-time algorithm [Kuperberg05]. Claimed polynomial-time quantum algorithms for LWE in 2024 [Chen24] and for DCP in 2026 [Simon26] [GRZ26] were subsequently refuted or challenged, but illustrate that this remains an active research area. HQC-KEM relies on the hardness of decoding random quasi-cyclic codes in the Hamming metric, and efficient algorithms for DCP or LWE are not known to imply an efficient decoding algorithm for such codes.¶

Recent advances in the cryptanalysis of Goppa codes have challenged long-standing assumptions and led BSI to no longer recommend the ISO-standardized Classic McEliece [ISO18033-2-AMD2] for new developments [BSI]. While HQC-KEM [FIPS207] is also code-based like Classic McEliece, its security relies on the hardness of decoding random quasi-cyclic codes and is not affected by advances in cryptanalysis of Goppa codes.¶

The algorithms specified in this document provide algorithmic diversity, and the PQ/PQ and PQ/PQ/T hybrids provide a conservative design. They remain secure against quantum attackers unless both the lattice-based and code-based components are broken. Compared with FrodoKEM [ISO18033-2-AMD2], the combination of ML-KEM and HQC-KEM has significantly smaller key shares and requires roughly an order of magnitude fewer CPU cycles at the same security category [PQ-PQ]. These hybrids are particularly well suited to high-security applications where handshake latency is not a primary concern.¶

Cryptographic agility is the capability to quickly change cryptographic algorithms in response to evolving security requirements or newly discovered vulnerabilities, while maintaining interoperability and system functionality. Supporting both ML-KEM and HQC-KEM enables a system to transition between lattice-based and code-based key establishment. However, a session key established today should remain confidential for decades. This is why hybrid key establishment, particularly PQ/PQ hybrids, is important for key exchange, but the same rationale does not generally apply to digital signatures.¶

ML-KEM and HQC are both structured schemes built on polynomial rings, so a natural concern is that an attack exploiting ring structure might apply to both. The rings, however, differ in essential ways. ML-KEM works over Z_q[X]/(X²⁵⁶ + 1) with q = 3329. This ring splits into 128 quadratic factors, which ML-KEM exploits for fast NTT-based multiplication. Its secrets and errors are small in absolute value, and its security rests on the Module-LWE problem. HQC works over F₂[X]/(Xⁿ − 1), where n is a prime chosen so that Xⁿ − 1 factors only as (X − 1) times a single irreducible polynomial, deliberately limiting exploitable substructure. Its secrets and errors are sparse in Hamming weight, and its security rests on the quasi-cyclic syndrome decoding problem. The two rings therefore differ in characteristic, in how they factor, and in the notion of “small” on which hardness depends. No known attack technique or reduction establishes that an efficient solution to the underlying problem of one scheme would yield an efficient attack on the other.¶

5. IANA Considerations

This document requests that IANA register nine new entries in the TLS Supported Groups registry [IANA], according to the procedures in Section 6 of [RFC9847].¶

5.1. HQCKEM128

Value:: TBD1¶
Description:: HQCKEM128¶
DTLS-OK:: Y¶
Recommended:: N¶
Reference:: This document¶
Comment:: Standalone HQC-KEM-128¶

5.2. HQCKEM192

Value:: TBD2¶
Description:: HQCKEM192¶
DTLS-OK:: Y¶
Recommended:: N¶
Reference:: This document¶
Comment:: Standalone HQC-KEM-192¶

5.3. HQCKEM256

Value:: TBD3¶
Description:: HQCKEM256¶
DTLS-OK:: Y¶
Recommended:: N¶
Reference:: This document¶
Comment:: Standalone HQC-KEM-256¶

5.4. HQCKEM192X25519

Value:: TBD4¶
Description:: HQCKEM192X25519¶
DTLS-OK:: Y¶
Recommended:: N¶
Reference:: This document¶
Comment:: PQ/T hybrid combining HQC-KEM-192 with X25519¶

5.5. HQCKEM256X448

Value:: TBD5¶
Description:: HQCKEM256X448¶
DTLS-OK:: Y¶
Recommended:: N¶
Reference:: This document¶
Comment:: PQ/T hybrid combining HQC-KEM-256 with X448¶

5.6. HQCKEM192MLKEM768

Value:: TBD6¶
Description:: HQCKEM192MLKEM768¶
DTLS-OK:: Y¶
Recommended:: N¶
Reference:: This document¶
Comment:: PQ/PQ hybrid combining HQC-KEM-192 with ML-KEM-768¶

5.7. HQCKEM256MLKEM1024

Value:: TBD7¶
Description:: HQCKEM256MLKEM1024¶
DTLS-OK:: Y¶
Recommended:: N¶
Reference:: This document¶
Comment:: PQ/PQ hybrid combining HQC-KEM-256 with ML-KEM-1024¶

5.8. HQCKEM192MLKEM768X25519

Value:: TBD8¶
Description:: HQCKEM192MLKEM768X25519¶
DTLS-OK:: Y¶
Recommended:: N¶
Reference:: This document¶
Comment:: PQ/PQ/T hybrid combining HQC-KEM-192 with ML-KEM-768 and X25519¶

5.9. HQCKEM256MLKEM1024X448

Value:: TBD9¶
Description:: HQCKEM256MLKEM1024X448¶
DTLS-OK:: Y¶
Recommended:: N¶
Reference:: This document¶
Comment:: PQ/PQ/T hybrid combining HQC-KEM-256 with ML-KEM-1024 and X448¶

6. References

6.1. Normative References

[FIPS203]: "Module-lattice-based key-encapsulation mechanism standard", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.203, August 2024, <https://doi.org/10.6028/nist.fips.203>.
[FIPS207]: National Institute of Standards and Technology, "Hamming Quasi-Cyclic Key-Encapsulation Mechanism Standard (forthcoming)", FIPS 207, <https://csrc.nist.gov/projects/post-quantum-cryptography>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7748]: Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/rfc/rfc7748>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9001]: Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/rfc/rfc9001>.
[RFC9147]: Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/rfc/rfc9147>.
[RFC9846]: Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, <https://www.rfc-editor.org/rfc/rfc9846>.
[RFC9847]: Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025, <https://www.rfc-editor.org/rfc/rfc9847>.
[RFC9954]: Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid Key Exchange in TLS 1.3", RFC 9954, DOI 10.17487/RFC9954, July 2026, <https://www.rfc-editor.org/rfc/rfc9954>.
[SP800-227]: Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A., Silberg, H., and N. Waller, "Recommendations for key-encapsulation mechanisms", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.sp.800-227, September 2025, <https://doi.org/10.6028/nist.sp.800-227>.

6.2. Informative References

[BSI]: Federal Office for Information Security (BSI), "Notes on recent developments concerning Classic McEliece", 1 October 2026, <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Crypto/Notes_Classic_McEliece.pdf>.
[Chen24]: Chen, Y., "Quantum Algorithms for Lattice Problems", Cryptology ePrint Archive, Paper 2024/555, 2024, <https://eprint.iacr.org/2024/555>.
[ETSI-TS-103-744]: ETSI, "Quantum-safe Hybrid Key Exchanges", ETSI TS 103 744, February 2026, <https://www.etsi.org/deliver/etsi_ts/103700_103799/103744/01.02.02_60/ts_103744v010202p.pdf>.
[EU25]: "A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography", June 2025, <https://ec.europa.eu/newsroom/dae/redirection/document/117507>.
[EU26]: "EU Roadmap on PQC – Frequently Asked Questions", April 2026, <https://ec.europa.eu/newsroom/dae/redirection/document/132120>.
[GRZ26]: Gupte, A., Ragavan, S., and M. Zhandry, "The ePrint:2026/1591 Quantum Algorithm Does Not Solve DCP", Cryptology ePrint Archive, Paper 2026/1693, 2026, <https://eprint.iacr.org/2026/1693>.
[HQC]: HQC Team, "Hamming Quasi-Cyclic (HQC)", 22 August 2025, <https://pqc-hqc.org/doc/hqc_specifications_2025_08_22.pdf>.
[I-D.ietf-tls-mlkem]: Connolly, D., "ML-KEM Post-Quantum Key Agreement for TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-mlkem-11, 16 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-mlkem-11>.
[IANA]: "IANA TLS Supported Groups Registry", n.d., <https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8>.
[ISO18033-2-AMD2]: ISO/IEC, "Information technology — Security techniques — Encryption algorithms — Part 2: Asymmetric ciphers — Amendment 2", ISO/IEC 18033-2:2006/Amd 2:2026, 2026.
[Kuperberg05]: Kuperberg, G., "A Subexponential-Time Quantum Algorithm for the Dihedral Hidden Subgroup Problem", Society for Industrial & Applied Mathematics (SIAM), SIAM Journal on Computing vol. 35, no. 1, pp. 170-188, DOI 10.1137/s0097539703436345, January 2005, <https://doi.org/10.1137/s0097539703436345>.
[NCSC26]: "Nationella rekommendationer för övergången till kvantsäker kryptografi", May 2026, <https://www.ncsc.se/siteassets/publikationer/nationella-rekommendationer-for-overgangen-till-kvantsaker-kryptografi-2026_tga.pdf>.
[NISTIR8545]: Alagic, G., Bros, M., Ciadoux, P., Cooper, D., Dang, Q., Dang, T., Kelsey, J., Lichtinger, J., Liu, Y., Miller, C., Moody, D., Peralta, R., Perlner, R., Robinson, A., Silberg, H., Smith-Tone, D., and N. Waller, "Status report on the fourth round of the NIST post-quantum cryptography standardization process", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.ir.8545, March 2025, <https://doi.org/10.6028/nist.ir.8545>.
[PQ-PQ]: Mattsson, J. P., Thormarker, E., Selander, G., Paavolainen, S., Ruohomaa, S., Sääskilahti, J., Hartley, T., Mazinani, H. V., and M. Kahn, "ML-KEM is Great! What's Missing?", NIST Workshop on Guidance for KEMs, 2025, <https://csrc.nist.gov/csrc/media/Events/2025/workshop-on-guidance-for-kems/documents/papers/ml-kem-is-great-paper.pdf>.
[Regev04]: Regev, O., "Quantum Computation and Lattice Problems", Society for Industrial & Applied Mathematics (SIAM), SIAM Journal on Computing vol. 33, no. 3, pp. 738-760, DOI 10.1137/s0097539703440678, January 2004, <https://doi.org/10.1137/s0097539703440678>.
[RFC9794]: Driscoll, F., Parsons, M., and B. Hale, "Terminology for Post-Quantum Traditional Hybrid Schemes", RFC 9794, DOI 10.17487/RFC9794, June 2025, <https://www.rfc-editor.org/rfc/rfc9794>.
[RFC10024]: Kwiatkowski, K., Kampanakis, P., Westerbaan, B. E., and D. Stebila, "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3", RFC 10024, DOI 10.17487/RFC10024, August 2026, <https://www.rfc-editor.org/rfc/rfc10024>.
[Simon26]: Simon, D. R., "A Polynomial-Time Quantum Algorithm for the Dihedral Coset Problem", Cryptology ePrint Archive, Paper 2026/1591, 2026, <https://eprint.iacr.org/2026/1591>.
[SP800-12]: Nieles, M., Dempsey, K., and V. Pillitteri, "An introduction to information security", National Institute of Standards and Technology, DOI 10.6028/nist.sp.800-12r1, June 2017, <https://doi.org/10.6028/nist.sp.800-12r1>.
[SP800-57]: Barker, E. and W. Barker, "Recommendation for Key Management: Part 1 — General Initial Public Draft", National Institute of Standards and Technology, DOI 10.6028/nist.sp.800-57pt1r6.ipd, December 2025, <https://doi.org/10.6028/nist.sp.800-57pt1r6.ipd>.