In Hybrid key exchange in TLS 1.3, they mention that with a hybrid approach, we concatenate the shared secret from each method (say KEM like Kyber768 + classical ECDH X25519 = X22519Kyer768).

     concatenated_shared_secret = shared_secret_1 || shared_secret_2

The idea for the hybrid is that it is quantum safe to protect against store now/decrypt later attacks and that the classical X25519 is known to be good today as a backup in case Kyber is broken.

What I am failing to see is how the key exchange actually works.

How do you do this concatenation to actually be secure against both classical and quantum attacks? Aren't you still doing a single TLS 1.3 key exchange and why wouldn't that be insecure against store now / decrypt later attacks if using X25519 or if you are only using a Kyber768 KEM, wouldn't that be insecure against classical attacks if Kyber is broken?

How does this concatenation provide the simultaneous benefit of both classical and quantum at the same time?


1 Answer 1


How does this concatenation provide the simultaneous benefit of both classical and quantum at the same time?

This proposal assumes the TLS 1.3 key derivation chain, where they perform an HKDF-Extract on the shared secret (that is, the concatenation of the classical and the postquantum shared secrets).

With HKDF-Extract, we cannot guess the output unless we know almost all the input bits. Because we assume that the adversary doesn't know either the classical shared secret (if Kyber is broken) or the postquantum shared secret (in the case of a quantum computer), the output is unpredictable (unless the adversary can break both).

Yes, this was a conscious decision made based on the key derivation structure of TLS; they may change to a more self-contained key derivation method (for example, in case some other protocol uses this concatenation method without the TLS structure)

  • $\begingroup$ But how do you get to that shared secret if you haven't performed both X25519 and then Kyber768. Don't you actually have to do both of those things before you can use HKDF-Extract to create the shared key? In other words, isn't this a chicken and egg problem? $\endgroup$
    – Moo
    Nov 9, 2023 at 11:58
  • 1
    $\begingroup$ It's not a chicken-and-egg; we do them both (in parallel). That is, the client keyshare consists of the x25519 keyshare and Kyber768 public key (concatinated together), and the server keyshare consists of the x25519 keyshare and the Kyber768 ciphertext (concatinated together). They compute both the x25519 and Kyber768 shared secrets, and concatinate them together $\endgroup$
    – poncho
    Nov 9, 2023 at 12:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.