RFC 9954

Hybrid Key Exchange in TLS 1.3

📅 published July 2026, from ietf

RFC 9954: Hybrid Key Exchange in TLS 1.3 🎀

okay so bestie, this one is from the Internet Engineering Task Force (IETF) 🌸 It's RFC 9954, published July 2026. The authors are D. Stebila (University of Waterloo), S. Fluhrer (Cisco Systems), and S. Gueron (U. Haifa & Meta) 👑. It's Informational, so it's not a Standards Track spec, and its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates ✨

Abstract 💜

okay so hybrid key exchange means using multiple key exchange algorithms at the same time and combining their results 🦋 The goal is that you stay secure even if someone finds a way to break all but one of the component algorithms. It's motivated by the move to post-quantum cryptography 🔮 This document gives a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol, version 1.3 💅

Status of This Memo 📜

this document is not an Internet Standards Track specification. It's published for informational purposes only 🌷

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that 🫶

For info about the current status of this document, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9954 🔗

Copyright (c) 2026 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/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for 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 they're provided without warranty as described in the Revised BSD License 🌈

Table of Contents 🧚

1.  Introduction
  1.1.  Terminology
  1.2.  Motivation for Use of Hybrid Key Exchange
  1.3.  Scope
  1.4.  Goals
2.  Key Encapsulation Mechanisms
3.  Construction for Hybrid Key Exchange
  3.1.  Negotiation
  3.2.  Transmitting Public Keys and Ciphertexts
  3.3.  Shared Secret Calculation
4.  Discussion
5.  IANA Considerations
6.  Security Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Appendix A.  Related Work
Acknowledgements
Authors' Addresses

1. Introduction ✨

okay so this doc gives a construction for hybrid key exchange in TLS 1.3 💖 The overall vibe is simple and "concatenation"-based. Each hybrid key exchange combination should be viewed as a single new key exchange method, and it should be negotiated and transmitted using the existing TLS 1.3 mechanisms 🎀

This document does not propose specific post-quantum mechanisms. For more on what's in scope, see Section 1.3 🌸

1.1. Terminology 🔤

bestie, this part is important. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in ALL CAPS like shown here 🫶

Next, it helps to split cryptographic algorithms into two classes 🦋

  • "Traditional" algorithms: These are widely deployed today but might get deprecated later. In TLS 1.3, traditional key exchange algorithms include Elliptic Curve Diffie-Hellman (ECDH) using secp256r1 or x25519, or finite field Diffie-Hellman 💜
  • "Next-generation" (or "next-gen") algorithms: These aren't widely deployed yet but might be someday. The cryptographic community may trust them less because they're relatively new or less studied. This includes "post-quantum" algorithms 🔮

so a "hybrid" key exchange uses two (or more) key exchange algorithms based on different cryptographic assumptions. For example, one traditional and one next-generation algorithm 🌈 The whole point is that the final session key stays secure as long as at least one component key exchange algorithm remains unbroken. When one is traditional and one is post-quantum, that's a Post-Quantum Traditional Hybrid Scheme [PQUIP-TERM]. That's the initial use case for this document, but the document isn't limited to it. This doc uses the term "component" algorithms for the algorithms combined in a hybrid key exchange ✨

Some researchers prefer the word "composite" for using multiple algorithms, to tell it apart from "hybrid public key encryption." In that one, a key encapsulation mechanism and a data encapsulation mechanism get combined to make public key encryption 🙈

The component algorithms in a hybrid key exchange are meant to be performed, meaning negotiated and transmitted, within the TLS 1.3 handshake. Any out-of-band method of exchanging keying material is out of scope 🚫

The main motivation here is preparing for post-quantum algorithms. But public key cryptography based on alternative mathematical constructions might be wanted too, to reduce risk regardless of whether a quantum computer shows up. For example, a cryptanalytic breakthrough could cause that. So this document goes with the more generic term "next-generation" algorithms, rather than only "post-quantum" algorithms 🧚

Also, TLS 1.3 uses the term "groups" for key exchange algorithms. The supported_groups extension is one example. That's because all key exchange algorithms in TLS 1.3 are Diffie-Hellman-based. As a result, some parts of this document use data structures or messages with "group" in their names, even when the algorithm is neither Diffie-Hellman-based nor a group 💅

1.2. Motivation for Use of Hybrid Key Exchange 🌷

a hybrid key exchange algorithm lets early adopters who are eager for post-quantum security get the potential of it (possibly from a less-well-studied algorithm), while still keeping at least the security traditional algorithms offer today 💖 They might even need to keep traditional algorithms because of regulatory constraints, like US National Institute of Standards and Technology (NIST) FIPS compliance 📋

Ideally, nobody would need hybrid key exchange. You'd have confidence in one algorithm and parameterization that stands the test of time 👑 But that may not be the case with quantum computers and cryptanalytic advances more generally 🔮

Lots of post-quantum algorithms under consideration are relatively new. They haven't been studied as deeply as RSA, finite field Diffie-Hellman, or elliptic curve Diffie-Hellman. So the security community doesn't necessarily have as much confidence in their fundamental security, or in the concrete security level of specific parameterizations 🙈

Also, after next-generation algorithms get defined, conservative users may not have full confidence in some of them for a while 🫠

Some users want to speed up post-quantum adoption because of retroactive decryption, also called "harvest-now-decrypt-later" 😭 If a cryptographic assumption breaks, because of a quantum computer or some other cryptanalytic breakthrough, the confidentiality of information can be broken retroactively by any adversary who passively recorded handshakes and encrypted communications. Hybrid key exchange gives potential protection against retroactive decryption without fully abandoning traditional cryptosystems 🦋

So there may be users for whom hybrid key exchange is a sensible step before an eventual move to next-generation algorithms ✨ Users should look at how much confidence they have in each hybrid component, to judge whether the hybrid system meets their goal 💜

1.3. Scope 🔭

this document focuses on hybrid ephemeral key exchange in TLS 1.3 [TLS13]. It intentionally does NOT address the following 🚫

  • Selecting which next-generation algorithms to use in TLS 1.3, or algorithm identifiers or encoding mechanisms for next-generation algorithms 🔤
  • Authentication using next-generation algorithms. While quantum computers could retroactively decrypt previous sessions, session authentication can't be retroactively broken 🫶

1.4. Goals 🎀

okay so the big boss goal of a hybrid key exchange 👑 is getting a shared secret that stays secure as long as one of the component key exchange mechanisms is still unbroken. so even if one of them gets cracked, you're still covered. main character energy fr 🦋

In the context of TLS 1.3, there may be several additional goals too:

  • Backwards compatibility: Clients and servers who are "hybrid-aware", i.e., compliant with whatever hybrid key exchange standard is developed for TLS, should remain compatible with endpoints and middleboxes that are not hybrid-aware. there are three scenarios to think about 🧚
    1. Hybrid-aware client, hybrid-aware server: These parties should establish a hybrid shared secret.
    2. Hybrid-aware client, non-hybrid-aware server: These parties should establish a non-hybrid shared secret (assuming the hybrid-aware client is willing to downgrade to non-hybrid-only).
    3. Non-hybrid-aware client, hybrid-aware server: These parties should establish a non-hybrid shared secret (assuming the hybrid-aware server is willing to downgrade to non-hybrid-only).

Ideally, backwards compatibility should be achieved without extra round trips and without sending duplicate information; see below. 🙈

  • High performance: Use of hybrid key exchange should not be prohibitively expensive in terms of computational performance. In general, this will depend on the performance characteristics of the specific cryptographic algorithms used and, as such, is outside the scope of this document. See [PST] for preliminary results about performance characteristics. 💅
  • Low latency: Use of hybrid key exchange should not substantially increase the latency experienced to establish a connection. Factors affecting this may include the following:
    • The computational performance characteristics of the specific algorithms used. See above.
    • The size of messages to be transmitted. Public key and ciphertext sizes for post-quantum algorithms range from hundreds of bytes to over one hundred kilobytes, so this impact can be substantial. See [PST] for preliminary results in a laboratory setting and [LANGLEY] for preliminary results on more realistic networks. the size thing is wild 😭
    • Additional round trips added to the protocol. See below.
  • No extra round trips: Attempting to negotiate hybrid key exchange should not lead to extra round trips in any of the three hybrid-aware/non-hybrid-aware scenarios listed above. ⭐
  • Minimal duplicate information: Attempting to negotiate hybrid key exchange should not mean having to send multiple public keys of the same type. 🍓

The tolerance for lower performance and increased latency due to use of hybrid key exchange will depend on the context and use case of the systems and the network involved. it's all vibes-dependent, bestie 🌸

2. Key Encapsulation Mechanisms ✨

This document models key agreement as key encapsulation mechanisms (KEMs), which consist of three algorithms:

  • KeyGen() -> (pk, sk): A probabilistic key generation algorithm, which generates a public key pk and a secret key sk.
  • Encaps(pk) -> (ct, ss): A probabilistic encapsulation algorithm, which takes as input a public key pk and outputs a ciphertext ct and shared secret ss.
  • Decaps(sk, ct) -> ss: A decapsulation algorithm, which takes as input a secret key sk and ciphertext ct and outputs a shared secret ss or, in some cases, a distinguished error value.

The main security property for KEMs is indistinguishability under adaptive chosen ciphertext attack (IND-CCA2), which means that shared secret values should be indistinguishable from random strings even given the ability to have other arbitrary ciphertexts decapsulated. IND-CCA2 corresponds to security against an active attacker, and the public key and secret key pair can be treated as a long-term key or reused. A common design pattern for obtaining security under key reuse is to apply the Fujisaki-Okamoto (FO) transform [FO] or a variant thereof [HHK]. the active attacker is the villain in this story 🦹

A weaker security notion is indistinguishability under chosen plaintext attack (IND-CPA), which means that the shared secret values should be indistinguishable from random strings given a copy of the public key. IND-CPA roughly corresponds to security against a passive attacker and sometimes corresponds to one-time key exchange.

See [KATZ] or [HHK] for definitions of IND-CCA2 and IND-CPA security. 📚

Key exchange in TLS 1.3 is phrased in terms of Diffie-Hellman key exchange in a group. DH key exchange can be modeled as a KEM, with (1) KeyGen corresponding to selecting an exponent x as the secret key and computing the public key g^x, (2) encapsulation corresponding to selecting an exponent y and computing the ciphertext g^y and the shared secret g^(xy), and (3) decapsulation corresponding to computing the shared secret g^(xy). See [HPKE] for more details of such Diffie-Hellman-based key encapsulation mechanisms. Diffie-Hellman key exchange, when viewed as a KEM, does not formally satisfy IND-CCA2 security but is still safe to use for ephemeral key exchange in TLS 1.3; see, for example, [DOWLING]. 🦋

TLS 1.3 does not require that ephemeral public keys be used only in a single key exchange session; some implementations may reuse them, at the cost of limited forward secrecy. As a result, any KEM used in the manner described in this document MUST explicitly be designed to be secure in the event that the public key is reused. Finite field and elliptic curve Diffie-Hellman key exchange methods used in TLS 1.3 satisfy this criteria. For generic KEMs, this means satisfying IND-CCA2 security or having a transform like the Fujisaki-Okamoto transform [FO] [HHK] applied. While it is recommended that implementations avoid reuse of KEM public keys, implementations that do reuse KEM public keys MUST ensure that the number of reuses of a KEM public key abides by any bounds in the specification of the KEM or subsequent security analyses. Implementations MUST NOT reuse randomness in the generation of KEM ciphertexts. 🚨 no randomness recycling, periodt 💀

3. Construction for Hybrid Key Exchange 👑

3.1. Negotiation 💖

Each particular combination of algorithms in a hybrid key exchange will be represented as a NamedGroup and sent in the supported_groups extension. No internal structure or grammar is implied or required in the value of the identifier; they are simply opaque identifiers. ✨

Each value representing a hybrid key exchange will correspond to an ordered pair of two or more algorithms. (Note that this is independent from future documents standardizing solely post-quantum key exchange methods, which would have to be assigned their own identifier.) 🌈

3.2. Transmitting Public Keys and Ciphertexts 🦋

This document takes the relatively simple "concatenation approach": The messages from the two or more algorithms being hybridized will be concatenated together and transmitted as a single value to avoid having to change existing data structures. The values are directly concatenated, without any additional encoding or length fields; the representation and length of elements MUST be fixed once the algorithm is fixed. simple, but it has to be exact 🎀

Recall that, in TLS 1.3 ([TLS13], Section 4.2.8), a KEM public key or KEM ciphertext is represented as a KeyShareEntry:

struct {
    NamedGroup group;
    opaque key_exchange<1..2^16-1>;
} KeyShareEntry;

These are transmitted in the extension_data fields of KeyShareClientHello and KeyShareServerHello extensions:

struct {
    KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello;

struct {
    KeyShareEntry server_share;
} KeyShareServerHello;

The client's shares are listed in descending order of client preference; the server selects one algorithm and sends its corresponding share.

For a hybrid key exchange, the key_exchange field of a KeyShareEntry is the concatenation of the key_exchange field for each of the constituent algorithms. The order of shares in the concatenation MUST be the same as the order of algorithms indicated in the definition of the NamedGroup. 🔥 order matters, no exceptions

For the client's share, the key_exchange value contains the concatenation of the pk outputs of the corresponding KEMs' KeyGen algorithms if that algorithm corresponds to a KEM or the (EC)DH ephemeral key share if that algorithm corresponds to an (EC)DH group. For the server's share, the key_exchange value contains the concatenation of the ct outputs of the corresponding KEMs' Encaps algorithms if that algorithm corresponds to a KEM or the (EC)DH ephemeral key share if that algorithm corresponds to an (EC)DH group.

Section 4.2.8 of [TLS13] requires that "The key_exchange values for each KeyShareEntry MUST be generated independently." In the context of this document, the same algorithm may appear in multiple named groups; thus, this document relaxes the above requirement to allow the same key_exchange value for the same algorithm to be reused in multiple KeyShareEntry records sent within the same ClientHello. However, key_exchange values for different algorithms MUST be generated independently. Explicitly, if the NamedGroup is the hybrid key exchange MyECDHMyPQKEM, the KeyShareEntry.key_exchange values MUST be generated in one of the following two ways: 🫶

Fully independently:

MyECDHMyPQKEM.KeyGen() = (MyECDH.KeyGen(), MyPQKEM.KeyGen())

KeyShareClientHello {
    KeyShareEntry {
        NamedGroup: 'MyECDH',
        key_exchange: MyECDH.KeyGen()
    },
    KeyShareEntry {
        NamedGroup: 'MyPQKEM',
        key_exchange: MyPQKEM.KeyGen()
    },
    KeyShareEntry {
        NamedGroup: 'MyECDHMyPQKEM',
        key_exchange: MyECDHMyPQKEM.KeyGen()
    },
}

Reusing key_exchange values of the same component algorithm within the same ClientHello:

myecdh_key_share = MyECDH.KeyGen()
mypqkem_key_share = MyPQKEM.KeyGen()
myecdh_mypqkem_key_share = (myecdh_key_share, mypqkem_key_share)

KeyShareClientHello {
    KeyShareEntry {
        NamedGroup: 'MyECDH',
        key_exchange: myecdh_key_share
    },
    KeyShareEntry {
        NamedGroup: 'MyPQKEM',
        key_exchange: mypqkem_key_share
    },
    KeyShareEntry {
        NamedGroup: 'MyECDHMyPQKEM',
        key_exchange: myecdh_mypqkem_key_share
    },
}

3.3. Shared Secret Calculation 💖

okay so for the shared secret, this doc goes with a super simple "concatenation approach" 🧚 Both shared secrets just get stuck together, and that blob becomes the shared secret in the existing TLS 1.3 key schedule. No extra structure gets added to the concatenation, so no length fields either 🙈 For both the traditional groups and the post-quantum KEMs, the shared secret output length is already fixed for a specific elliptic curve or parameter set ✨

So if the NamedGroup is MyECDHMyPQKEM, the shared secret gets calculated like this:

   concatenated_shared_secret = MyECDH.shared_secret
                                || MyPQKEM.shared_secret

Then that concatenated secret gets plugged into the TLS 1.3 key schedule in place of the (EC)DHE shared secret, as shown in Figure 1 🦋

                                       0
                                       |
                                       v
                         PSK ->  HKDF-Extract = Early Secret
                                       |
                                       +-----> Derive-Secret(...)
                                       +-----> Derive-Secret(...)
                                       +-----> Derive-Secret(...)
                                       |
                                       v
                                 Derive-Secret(., "derived", "")
                                       |
                                       v
   concatenated_shared_secret -> HKDF-Extract = Handshake Secret
   ^^^^^^^^^^^^^^^^^^^^^^^^^^          |
                                       +-----> Derive-Secret(...)
                                       +-----> Derive-Secret(...)
                                       |
                                       v
                                 Derive-Secret(., "derived", "")
                                       |
                                       v
                            0 -> HKDF-Extract = Main Secret
                                       |
                                       +-----> Derive-Secret(...)
                                       +-----> Derive-Secret(...)
                                       +-----> Derive-Secret(...)
                                       +-----> Derive-Secret(...)

               Figure 1: Key Schedule for Hybrid Key Exchange

Now the FIPS compliance bit 🧐 The US National Institute of Standards and Technology (NIST) documents [NIST-SP-800-56C] and [NIST-SP-800-135] give recommendations for key derivation methods in key exchange protocols. Some hybrid combos might mix a shared secret from a NIST-approved algorithm (like ECDH using the nistp256/secp256r1 curve) with one from an unapproved algorithm (like post-quantum). [NIST-SP-800-56C] lists simple concatenation as an approved method for generating a hybrid shared secret where one of the constituent shared secrets comes from an approved method ✨

4. Discussion 🔥

Larger public keys and/or ciphertexts: The key_exchange field in the KeyShareEntry struct in Section 3.2 limits public keys and ciphertexts to 2^16-1 bytes. Some post-quantum KEMs have bigger public keys and/or ciphertexts. For example, Classic McEliece's smallest parameter set has a public key size of 261,120 bytes [Classic-McEliece] 😭 But all the defined parameter sets for the Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) [NIST-FIPS-203] have public keys and ciphertexts that fit within the TLS constraints. Just know this might make ClientHello messages bigger than a single packet 📦

Duplication of key shares: Concatenating public keys in the key_exchange field of the KeyShareEntry struct, as described in Section 3.2, can end up sending duplicate key shares 👯 For example, if a client wants to offer support for two combinations, say "SecP256r1MLKEM768" and "X25519MLKEM768" [ECDHE-MLKEM], it would end up sending two ML-KEM-768 public keys, since the KeyShareEntry for each combination has its own copy of an ML-KEM-768 key. This duplication could be more of a problem for post-quantum algorithms with larger public keys. On the other hand, if the client wants to offer, for example, "SecP256r1MLKEM768" and "secp256r1" (for backwards compatibility), there's relatively little duplicated data, since the secp256r1 keys are comparatively small 🌸

5. IANA Considerations 🌸

IANA has added this document as a reference for the "TLS Supported Groups" registry [IANA-TLS] 📖

For hybrid combinations defined per this document, IANA will assign identifiers in a range that is distinct from the Finite Field Groups range. Also, the "Recommended" column SHOULD be "N", and the "DTLS-OK" column SHOULD be "Y" ✨

6. Security Considerations 💀

This part is serious, bestie, so read it carefully 🫶 The shared secrets computed in the hybrid key exchange should be computed in a way that achieves the "hybrid" property. In other words, the resulting secret is secure as long as at least one of the component key exchange algorithms is unbroken. See [GIACON] and [BINDEL] for an investigation of these issues. Under the assumption that shared secrets are fixed length once the combination is fixed, the construction in Section 3.3 corresponds to the dual-PRF combiner of [BINDEL], which is shown to preserve security under the assumption that the hash function is a dual-PRF.

As noted in Section 2, KEMs used in the manner described in this document MUST explicitly be designed to be secure in the event that the public key is reused, such as by achieving IND-CCA2 security or by having a transform like the Fujisaki-Okamoto transform applied. ML-KEM has such security properties. However, some other post-quantum KEMs designed to be IND-CPA-secure (i.e., without countermeasures such as the FO transform) are completely insecure under public key reuse. For example, some lattice-based IND-CPA-secure KEMs are vulnerable to attacks that recover the private key after just a few thousand samples [FLUHRER] 😱

Public keys, ciphertexts, and secrets should be constant length. This document assumes that the length of each public key, ciphertext, and shared secret is fixed once the algorithm is fixed. This is the case for ML-KEM.

Note that variable-length secrets are, generally speaking, dangerous 🚨 In particular, when you use key material of variable length and process it with hash functions, a timing side channel may arise. Broadly speaking, when the secret is longer, the hash function may need to process more blocks internally. In some unfortunate circumstances, this has led to timing attacks, e.g., the Lucky Thirteen [LUCKY13] and Raccoon [RACCOON] attacks.

Furthermore, [AVIRAM] identifies a risk of using variable-length secrets when the hash function used in the key derivation function is no longer collision-resistant.

If concatenation were to be used with values that are not fixed length, a length prefix or other unambiguous encoding would need to be used to ensure that the composition of the two values is injective, and it would require a mechanism different from the one specified in this document 🙅‍♀️

Therefore, this specification MUST only be used with algorithms that have fixed-length shared secrets (after the variant has been fixed by the algorithm identifier in the NamedGroup negotiation in Section 3.1). No cap, this one is non-negotiable 👑

7. References 📚

7.1. Normative References

Here's the reading list, with every detail kept 🎀

   [FO]       Fujisaki, E. and T. Okamoto, "Secure Integration of
              Asymmetric and Symmetric Encryption Schemes", Journal of
              Cryptology, vol. 26, no. 1, pp. 80-101,
              DOI 10.1007/s00145-011-9114-1, December 2011,
              <https://doi.org/10.1007/s00145-011-9114-1>.

   [HHK]      Hofheinz, D., Hövelmanns, K., and E. Kiltz, "A Modular
              Analysis of the Fujisaki-Okamoto Transformation", Theory
              of Cryptography (TCC 2017), Lecture Notes in Computer
              Science, vol. 10677, pp. 341-371,
              DOI 10.1007/978-3-319-70500-2_12, 2017,
              <https://doi.org/10.1007/978-3-319-70500-2_12>.

   [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/info/rfc2119>.

   [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/info/rfc8174>.

   [TLS13]    Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
              <https://www.rfc-editor.org/info/rfc9846>.

7.2. Informative References ✨

okay bestie, this is the bibliography 📚💅 these are the informative references, aka the receipts and background reading that back up the whole spec 🧾 I kept every single one, all the authors, titles, dates, DOIs and links exactly as they are 🫶

okay so quantum computing and post-quantum cryptography in general are outside the scope of this doc, bestie 💅 for a general intro to quantum computing, grab a standard textbook like [NIELSEN]. for an overview of post-quantum crypto as of 2009, see [BERNSTEIN]. it's not up to date with newer stuff, but it's still a super helpful starting point 📚 for the current status of the NIST Post-Quantum Cryptography Standardization Project, see [NIST]. and for more perspectives on moving from traditional to post-quantum crypto, see for example [ETSI], among others 🌈

there have been several Internet-Drafts describing ways to embed post-quantum and/or hybrid key exchange in TLS, and they're giving main character energy ✨

  • TLS 1.2: [WHYTE12], [CAMPAGNA]
  • TLS 1.3: [KIEFER], [SCHANCK], [WHYTE13]

there have also been several prototype implementations of post-quantum and/or hybrid key exchange in TLS 🛠️

  • TLS 1.2: [BCNS15], [CECPQ1], [FRODO], [OQS-102], [S2N]
  • TLS 1.3: [CECPQ2], [OQS-111], [OQS-PROV], [PST]

these experimental implementations took an ad hoc approach and did not try to implement any of the Internet-Drafts listed above. messy but iconic 😭

unrelated to post-quantum, but still connected to the issue of combining multiple types of keying material in TLS, is the use of pre-shared keys. especially the recent TLS Working Group document on including an external pre-shared key [EXTERN-PSK] 🔑

[RFC9370] covers multiple key exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2), and it's been published as a Proposed Standard 🎀 other IETF work includes post-quantum preshared keys in IKEv2 [IKE-PSK]. and the eXtended Merkle Signature Scheme (XMSS) hash-based signature scheme has been published as an Informational RFC by the IRTF [XMSS] 🌸

in the academic literature, [EVEN] started the study of combining multiple symmetric encryption schemes. [ZHANG], [DODIS], and [HARNIK] looked at combining multiple public key encryption schemes. and [HARNIK] coined the term "robust combiner" for a compiler that builds a hybrid scheme from individual schemes while preserving security properties. [GIACON] and [BINDEL] examined combining multiple key encapsulation mechanisms 🧠💜

Acknowledgements 🫶

the ideas in this document grew out of discussions with lots of colleagues, including Christopher Wood, Matt Campagna, Eric Crockett, Deirdre Connolly, the authors of the various hybrid documents and implementations cited here, and members of the TLS Working Group 💖 the immediate spark came from chats with attendees at the Workshop on Post-Quantum Software in Mountain View, California in January 2019 ✨ Daniel J. Bernstein and Tanja Lange commented on the risks of reusing ephemeral public keys 🙈 Matt Campagna and the team at Amazon Web Services gave extra suggestions. and Nimrod Aviram proposed restricting to fixed-length secrets 🍓

Authors' Addresses 🌷

Douglas Stebila University of Waterloo Email: dstebila@uwaterloo.ca

Scott Fluhrer Cisco Systems Email: sfluhrer@cisco.com

Shay Gueron University of Haifa and Meta Email: shay.gueron@gmail.com

and that's a wrap on the whole RFC, bestie 🌈👑

📦 where this page comes from