As we’re already accustomed to, the web becomes more secure every single day. This time around, we’re discussing two emerging standards: Kyber-based hybrid post-quantum key exchange and ECH. Both are currently “Active Internet-Draft”s, yet they’ve already begun to roll out on major sites, at least one of them.
Let’s start with Kyber. Now that we have quantum computers and their qubits are ever-increasing, we need to start thinking about protecting our quantum-vulnerable encryption algorithms against them. Fortunately, this neither means that your data is at risk now or that we need to replace all cryptography at use today. The algorithms vulnerable to quantum computers implementing Shor’s algorithm are the ones used for key exchange, the part of an encrypted communication responsible for setting up a shared key. The biggest ones we’re aiming to replace are DH, ECDH, and RSA.
NIST is on track to standardize the Lattice-based CRYSTALS-Kyber algorithm as a successor to the vulnerable ones by 2024. Some very clever engineers have already embarked on real-world implementations: Signal recently unveiled their take on the impending standard: Post-Quantum Extended Diffie-Hellman or PQXDH for short. The Signal protocol update features a hybrid1 blend of the current KEM, X25519 (ECDH), and CRYSTALS-Kyber, for a simple reason: new encryption standards, are often broken2, but rarely on day one. This approach mirrors the trajectory of the latest post-quantum hybrid key agreement algorithms for TLS: X25519Kyber512Draft00 and X25519Kyber768Draft00, both encapsulating X25519 + Kyber. They have been under beta testing by tech giants like Google and Cloudflare for over a year now. [1]
This means that most sites proxied through Cloudflare already support Kyber512 and Kyber768 key agreements. The list also includes Google-owned sites like YouTube and Google Drive, but to find Amazon or Microsoft’s sites, you’d have to look elsewhere. Adoption is rolling out slowly but surely, but the bigger issue here are the clients: only the latest of Chrome supports it3, with other clients like curl
and most programming language’s network APIs still lacking any progress — most likely, we will have to wait until finalization of the proposal for further adoption.
Next is up ECH, which is solving an issue of the present. As you may know, technologies like DoH and TLS help to keep snoopers away from your network traffic. The last piece of the puzzle is ClientHello, the packet responsible for negotiating a TLS session, which contains information including the SNI, describing the hostname the client is requesting a certificate for. This meant that, for anyone listening for packets traveling over the network (be that your place of work, school, or the ISP in case of your own home) they could see all the domains you were visiting. With Encrypted Client Hello, the SNI is encrypted (the encrypted part is called inner ClientHello) and only the common name (SNI) is requested in plaintext (outer ClientHello).
Without ECH | With ECH |
---|---|
! |
To summarize, ECH is a great feature for improving online privacy for many, the need to use a VPN (for personal use). It has great support among browsers, with both Chrome and Firefox leading the way4. Client support is awesome to see, but in this case, we have an opposite problem to the one of Kyber PEMs: virtually no service accepts encrypted client hellos. I can only speculate about why I think that is: my opinions range from “c’mon, this was literally released yesterday” to the fact that this has big implications on security policies in enterprise and in places like schools, where some websites tend to be blocked. On the latter, the Encrypted Client Hello Deployment Considerations document explains these caveats in detail.
Personally, I hold ECH as a massive improvement to the overall digital landscape and would encourage anyone on Cloudflare to flip the switch. For other providers, I’d wait until ECH becomes easily available for you.
I would love to make a blog post series out of this concept of web security: I named it “CipherTrail Chronicles” and hope to see you on episode 2. To close off the post on an informative note, here is an overview of some notable domains and their support status (as of September 2023)5:
Domain | Protocol | Key exchange | ECH support | Cloudflare? |
---|---|---|---|---|
tiktok.com |
TLS 1.3 | X25519 | No | ❌ |
twitter.com |
TLS 1.3 | X25519 | No | ❌ |
github.com |
TLS 1.3 | X25519 | No | ❌ |
npmjs.com |
TLS 1.3 | X25519Kyber768Draft00 | No | ✅ |
cloudflare.com |
QUIC | X25519Kyber768Draft00 | No | ✅ |
apple.com |
TLS 1.3 | X25519 | No | ❌ |
netflix.com |
TLS 1.3 | X25519 | No | ❌ |
vercel.com |
TLS 1.3 | X25519 | No | ❌ |
google.com |
QUIC | X25519Kyber768Draft00 | No | ❌ |
instagram.com |
QUIC | X25519 | No | ❌ |
shopify.com |
QUIC | X25519Kyber768Draft00 | No | ✅ |
drive.google.com |
QUIC | X25519Kyber768Draft00 | No | ❌ |
youtube.com |
QUIC | X25519Kyber768Draft00 | No | ❌ |
interclip.app |
QUIC | X25519Kyber768Draft00 | Yes | ✅ |
Further reading:
- This blog is heavily based on the following writings from Cloudflare:
References:
- X25519Kyber768Draft00 hybrid post-quantum KEM for HPKE
- Some domains taken from Cloudflare Radar’s Top 100 domains (on 09/30/2023)
- PQXDH Spec
- Encrypted Client Hello on Wikipedia
-
Hybrid means that it is a combination of two algorithms. This implies double encryption of all data, meaning that the key agreement can only be so weak as is its strongest component. ↩
-
Although only X25519Kyber768Draft00 is supported in Chrome. ↩
-
The only notable omission here is Safari and iOS / iPadOS in general. ↩
-
Tested on Chrome 117.0.5938.62 with both ECH and Kyber flags enabled. ↩