For those scratching their heads over what TLS is, think of it as the superhero cape for your online escapades! It’s TLS to the rescue, swooping in to save the day by making online banking, shopping, and messaging as secure and snug as a panda in bamboo pajamas. So, fret not, your digital adventures are in safe, encrypted hands! 🦸♂️🔒
This article is the outcome of ongoing research and development efforts at EXAMROOM.AI in the field of post-quantum cryptography.
Notes:
“SSL” and “TLS” are often used interchangeably in this context.
Hybrid Key Exchange is also know as Composite Key Exchange.
Transport Layer Security (TLS) is a fundamental protocol utilized over TCP to establish secure connections, most notably in the form of HTTPS for web communications. In August 2018, the Internet Engineering Task Force (IETF) released the latest iteration of TLS, known as “Transport Layer Security (TLS) Protocol Version 1.3” [TLS 1.3]. Five years later, in September 2023, IETF introduced a significant addition to TLS 1.3 through an Internet-Draft titled “Hybrid Key Exchange in TLS 1.3”. This addition aimed to integrate post-quantum security into TLS communications, addressing the emerging need for quantum-resistant cryptography.
An official journey of TLS
However, despite this advancement, there are currently no official standards or specifications for full/hybrid post-quantum TLS, as the standardization of post-quantum algorithms is still ongoing. Nonetheless, notable entities like Apple have already taken steps to upgrade their messaging protocols, such as iMessage, to incorporate post-quantum security through the PQ3 protocol [Apple].
In this article, we will explore where does “Hybrid Key Exchange” fits into TLS 1.3. Prior knowledge of TLS 1.3 and basic cryptography is recommended to fully appreciate the content discussed.
Some basics of TLS 1.3
We will go through some concepts of TLS 1.3 here to make a foundation for understanding of Hybrid Key Exchange.
Ephemeral Key Exchange in TLS 1.3
In TLS 1.3, the ephemeral key exchange algorithms primarily used are “DHE” (Diffie-Hellman Ephemeral) and “ECDHE” (Elliptic Curve Diffie-Hellman Ephemeral), depending on whether it’s based on finite fields or elliptic curves, respectively. These algorithms facilitate the generation of temporary, session-specific keys to establish secure communication between the client and the server. Each session uses a unique ephemeral key pair, providing a Perfect Forward Secrecy (PFS). For undertanding it better, let’s understand TLS 1.3 full handshake protocol.
TLS 1.3 Full Handshake Protocol
The TLS 1.3 full handshake process is like a secure conversation between your web browser and a website. It involves three main steps as you can see in figure below: first, they agree on how to exchange secret keys for encryption, then they set up other important details like what encryption algorithms to use, and finally, they verify each other’s identity to make sure they’re both who they say they are. This ensures that the communication is secure and protected from eavesdropping or tampering.
TLS Handshake in brief
To establish communication between a client and a server, the client starts by sending a “ClientHello” message to the server. This message contains several pieces of information as below:
ClientHello {
ProtocolVersion: TLS 1.3
Random: <32 bytes of random data>
SessionID: <Empty, or session identifier if resuming a session>
CipherSuites: [
TLS_AES_256_GCM_SHA384,
TLS_CHACHA20_POLY1305_SHA256,
TLS_AES_128_GCM_SHA256
]
SupportedGroups: [
secp256r1 (Elliptic Curve Diffie-Hellman key exchange),
x25519 (Elliptic Curve Diffie-Hellman key exchange with Curve25519),
x448 (Elliptic Curve Diffie-Hellman key exchange with Curve448)
]
SupportedVersions: [
TLS 1.3
]
Extensions: [
SupportedVersions (indicating support for TLS 1.3),
KeyShare (containing the client’s key share for key exchange),
SignatureAlgorithms (supported signature algorithms for certificate authentication),
ServerName (indicating the server hostname),
SupportedGroups (additional supported groups for key exchange),
ApplicationLayerProtocolNegotiation (ALPN, indicating support for application-layer protocols like HTTP/2)
]
}
To display the detailed information of “ClientHello” message, let’s initiate a connection to the server “examroom.ai” (you can use any domain name) on port 443 using the OpenSSL s_client tool as shown below-
openssl s_client -connect examroom.ai:443 -tls1_3 -msg
Connecting to 13.248.211.74
CONNECTED(00000003)
>>> TLS 1.0, RecordHeader [length 0005]
16 03 01 00 f6
>>> TLS 1.3, Handshake [length 00f6], ClientHello
01 00 00 f2 03 03 d8 c2 e8 ee 1b 22 80 39 ed 72
df cd 87 b6 5f e4 0f 59 81 5f 62 d9 e3 f1 f6 bd
e4 7b cf 50 b6 68 20 0c 3e 9b 17 c8 19 c5 0d bc
dc df 76 78 81 80 d8 cb 52 6e 11 d5 42 e4 d2 28
72 c6 63 28 3a 69 bc 00 06 13 02 13 03 13 01 01
00 00 a3 00 00 00 12 00 10 00 00 0d 63 72 65 64
65 6e 74 69 61 2e 63 6f 6d 00 0b 00 04 03 00 01
02 00 0a 00 16 00 14 00 1d 00 17 00 1e 00 19 00
18 01 00 01 01 01 02 01 03 01 04 00 23 00 00 00
16 00 00 00 17 00 00 00 0d 00 24 00 22 04 03 05
03 06 03 08 07 08 08 08 1a 08 1b 08 1c 08 09 08
0a 08 0b 08 04 08 05 08 06 04 01 05 01 06 01 00
2b 00 03 02 03 04 00 2d 00 02 01 01 00 33 00 26
00 24 00 1d 00 20 59 a4 1a 3b 9c 88 48 52 91 32
78 e8 b5 3b 17 32 99 66 a6 e1 4b 5f 0f fa 59 9e
83 ce 24 fb 6c 21
In response to the aforementioned “ClientHello” message, the server provides a structured reply known as the “ServerHello” as shown below-
ServerHello {
“ProtocolVersion”: “TLS 1.3”,
“Random”: “<32 bytes of random data>”,
“CipherSuite”: “TLS_AES_256_GCM_SHA384”,
“Group”: “secp256r1”,
“KeyShare”: “<Server’s key share for key exchange>”,
“Extensions”: [
“SupportedVersions (indicating support for TLS 1.3)”,
“KeyShare (containing the server’s key share for key exchange)”,
“SignatureAlgorithms (supported signature algorithms for certificate authentication)”,
“ServerName (indicating the server hostname)”,
“ApplicationLayerProtocolNegotiation (ALPN, indicating support for application-layer protocols like HTTP/2)”
]
}
An example of the “ServerHello” message is provided below, demonstrating the server’s formal acknowledgment and establishment of key parameters in response to the client’s TLS 1.3 negotiation-
<<< TLS 1.3, Handshake [length 007a], ServerHello
02 00 00 76 03 03 51 e9 89 6a c7 ff cc cc 72 f8
aa 64 a4 60 22 fa c5 7e 12 c2 c5 21 ca 00 85 33
3b c9 b8 b8 6e ba 20 0c 3e 9b 17 c8 19 c5 0d bc
dc df 76 78 81 80 d8 cb 52 6e 11 d5 42 e4 d2 28
72 c6 63 28 3a 69 bc 13 01 00 00 2e 00 2b 00 02
03 04 00 33 00 24 00 1d 00 20 81 c2 85 5f a8 81
a6 09 fe f9 c6 25 cc 80 67 39 83 c0 b5 71 12 79
f8 c7 5c 92 31 4f 79 cd b6 5e
<<< TLS 1.2, RecordHeader [length 0005]
14 03 03 00 01
<<< TLS 1.2, RecordHeader [length 0005]
17 03 03 00 1b
<<< TLS 1.3, InnerContent [length 0001]
16
<<< TLS 1.3, Handshake [length 000a], EncryptedExtensions
08 00 00 06 00 04 00 00 00 00
<<< TLS 1.2, RecordHeader [length 0005]
17 03 03 14 81
<<< TLS 1.3, InnerContent [length 0001]
16
<<< TLS 1.3, Handshake [length 1470], Certificate
0b 00 14 6c 00 00 14 68 00 04 eb 30 82 04 e7 30
82 03 cf a0 03 02 01 02 02 12 04 74 ca 90 3a c6
28 d6 9c a0 ed 0e 51 35 c7 e1 4d 19 30 0d 06 09
2a 86 48 86 f7 0d 01 01 0b 05 00 30 32 31 0b 30
09 06 03 55 04 06 13 02 55 53 31 16 30 14 06 03
55 04 0a 13 0d 4c 65 74 27 73 20 45 6e 63 72 79
70 74 31 0b 30 09 06 03 55 04 03 13 02 52 33 30
1e 17 0d 32 34 30 31 33 30 30 37 32 33 31 37 5a
17 0d 32 34 30 34 32 39 30 37 32 33 31 36 5a 30
………………………………………..
………………………………………..
The comprehensive snapshot detailing the key parameters and session ticket specifics of an SSL session post-handshake is provided below-
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_128_GCM_SHA256
Session-ID: 63994569EC6E69C30928C58FC0826F51579020454E59AEAE7AC7FBC6D6CE60C2
Session-ID-ctx:
Resumption PSK: 59AE91CF9164DAE147D50C9C906AD10C38C78E62E5AE870F7B237D7956859A78
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 86400 (seconds)
TLS session ticket:
0000 – 40 67 87 4d 89 d3 0b 75-71 30 9d 07 ad 04 b1 2c @g.M…uq0…..,
0010 – c4 60 ec cd 12 25 9f a7-5f c3 5d c9 84 8f fe 79 .`…%.._.]….y
0020 – b4 92 2b b7 5c e1 93 37-e5 f8 da e3 73 e8 3d 6a ..+.\..7….s.=j
0030 – 36 bf bf bc 50 af 70 e2-da e2 ea 6f 01 b7 1b 8e 6…P.p….o….
0040 – 6b 66 2a a6 e7 a7 6a a9-19 bf 48 d6 a5 e1 24 cc kf*…j…H…$.
0050 – ae e8 de f4 ed 3c 88 41-72 78 b3 e0 78 a8 60 77 …..<.Arx..x.`w
0060 – d0 b8 3c 2d dd 9d c0 76-70 ..<-…vp
Start Time: 1709887623
Timeout : 7200 (sec)
Verify return code: 20 (unable to get local issuer certificate)
Extended master secret: no
Max Early Data: 0
Hybrid Key Exchange in TLS 1.3
Classical Key Exchange + Post-Quantum Key Exchange = Hybrid Key Exchange
Hybrid Key Exchange entails the utilization of multiple key exchange algorithms, incorporating at least one classical and one post-quantum key exchange algorithm as shown in the figure below. In the context of the presented X25519Kyber768Draft00 example, X25519 represents a classical elliptic curve Diffie-Hellman key exchange employing Curve25519, while Kyber768Draft00 denotes a post-quantum key exchange algorithm.
Hybrid Key Exchange Methods addition to TLS 1.3
The inclusion of at least one classical key exchange algorithm serves to ensure backward compatibility with existing systems and protocols. This compatibility facilitates seamless integration with legacy infrastructure and ensures interoperability across a wide range of devices and platforms.
Conversely, the integration of at least one post-quantum key exchange algorithm aims to enhance security by mitigating the risks associated with potential future advancements in quantum computing. By incorporating post-quantum algorithms, such as Kyber768Draft00, the hybrid approach safeguards against “Harvest Now and Decrypt Later” attacks, where intercepted encrypted data could be decrypted in the future with the aid of quantum computers. The mechanism by which backward compatibility is achieved in Hybrid Key Exchange is delineated in the figure below-
Backward Compatibility of Hybrid Key Exchange to TLS 1.3
Concatenation in X25519Kyber768Draft00 for Hybrid TLS [SS]
The goal of Hybrid Key Exchange or Classic Key Exchange is establish a “Shared Secret” between a client and a server which can be used further for encrypting all communication using symmetric encryption and decryption. The “Shared Secret” remains inaccessible to both active and passive adversaries, ensuring the confidentiality and integrity of the communication.
Notes :
“Hybrid Key Exchange in TLS 1.3” document [Hybrid] focuses on ephemeral key exchange and not focuses on Digital Signatures.
OpenSSL provides libraries and tools for implementing the SSL/TLS protocols, including TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3. https://github.com/openssl/openssl
Check out Examroom.AI’s latest blogs for detailed insights into the implementation of Post-Quantum technology!
References:
[Apple] https://security.apple.com/blog/imessage-pq3/
[D. Stebila] https://www.youtube.com/watch?v=QyeJaxOLSdI&t;=1616s — by Douglas Steblia
[Hybrid] https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-09.html
[TLS 1.3][https://www.rfc-editor.org/rfc/pdfrfc/rfc8446.txt.pdf](https://www.rfc-editor.org/rfc/pdfrfc/rfc8446.txt.pdf)
[SS] https://www.ietf.org/id/draft-tls-westerbaan-xyber768d00-03.html
