## Introduction

Having written a post on how to use post-quantum cryptography with Caddy, I thought it might be interesting to delve into the standard itself a bit more. Here is a summary (very light on the maths) of how X25519Kyber768Draft00 works.

## What is X25519Kyber768Draft00?

The X25519 part refers to standard elliptic curve cryptography, which has been putting the ‘S’ in HTTPS for many years now. Kyber768 is a lattice-based public key encryption system. Unlike RSA or ECDHA, lattice-based cryptography is an area where a good quantum computer is thought to offer no particular advantage over silicon-based classical architecture. The ‘Draft00’ part of the name refers to the fact that the Kyber768 standard is still a work in progress: the American National Institute for Standards and Technology (NIST) proposed a provisional standard in 2023. Later this year (‘24), we will be getting a finalised version of the standard.

## A Brief Refresher on Key Exchange

Your browser and my webserver need to communicate with each other using a symmetric key cryptography tool called a ‘block cipher’. AES is typical for TLS connections. To do this, they need to agree on the shared secret (i.e. the block cipher’s encryption/decryption key) privately. Public key cryptography is too computationally expensive to use for all the communication between browser and server, but it can be used to secure this symmetric key.

## X25519 Meets Kyber768: A Match Made in Heaven

In a ’normal’ TLS 1.3 connection, encryption of the AES key tends to be done just with X25519. In hybrid elliptic curve/post-quantum key exchange, the AES key is broken into two halves: 32 bytes to be encrypted with classical elliptic curve cryptography, then 32 bytes to be encrypted with a lattice-based post-quantum cryptographic system. Reading the AES key that secures the HTTP traffic is like firing a missile on a submarine: you need both keys.

What if your traffic is intercepted under the **store-now-decrypt-later** threat model, and the eavesdropper revisits
the TLS handshake in years to come when decent quantum computers are available? They should only be able to read the
X25519 (elliptic curve) half of the AES key. And if Kyber768, not yet as battle-hardened as its curvy cousin, should
have some flaw rendering it less secure than we thought? That doesn’t give the attacker any better chance of reading the
classically encrypted first half of the key. Both things would have to go wrong at once for the block cipher key to be
legible to an attacker.

## Further Reading

I’ve done my best to keep the cryptography mathematics out of this post for a software engineering audience, but the interested reader will find Bas Westerbaan’s X25519Kyber768Draft00 standard a more detailed explanation. If you’re interested in how to install this cryptography system yourself, check out my post on post-quantum cryptography with Caddy.