Post-quantum cryptography

What is all this talk about post-quantum cryptography (PQC)? Do we really need to deal with this today? And does it affect IRC? In the article below I've tried to keep things readable for technical users, without needing to dive into cryptography.

Is it needed?

Quantum computers work differently than our current computers. They allow certain operations to be done incredibly fast. One of these things is that it would allow breaking "classical" public-key cryptography much faster than today. These classic public-key algorithms are used everywhere. Most importantly, they are used in SSL/TLS during the handshake to set up an encrypted connection (HTTPS, IRC with SSL/TLS, e-mail with STARTTLS, etc). Now, quantum computers are still under development. As far as we (publicly) know, a quantum computer of sufficient size and reliability does not exist yet and it seems like we still have a few years.

The threat, however, is clear and it makes sense to prepare for what is called Q-day. That's the day (of which we don't know the date yet) that quantum computers will be able to break those classic public-key algorithms. From that day onward, classic public-key algorithms are no longer safe.

Actually, the encrypted data can already be at risk before Q-day. But more on that later. Let's focus on what is used in the SSL/TLS key exchange first.

Switch to a pure quantum-safe algorithm?

Cryptographers have designed key exchange algorithms that are "quantum safe", that is: they would not be broken by a quantum computer. Unfortunately, those algorithms will also be quite new. The classic algorithms that we use today are well studied, a lot about them is known, where the weaknesses are, the threats, how to use them properly, and so on. Those new quantum-safe algorithms have not gone through as much scrutiny as classic crypto.

The dilemma: does the world move to a quantum-safe crypto algorithm, so data will be safe from a quantum computer but on the other hand it may have some other (major) weaknesses that have not come up yet, simply because the algorithm is "too new". Or do we stick with classic crypto algorithms, which we know are "good enough" right now, but are for sure broken by a good quantum computer (which doesn't exist yet).

The compromise: use both classic and quantum-safe

Fortunately crypto experts came up with a compromise: use both classic cryptography (the same we use today) and cryptography that is safe from quantum computers. The nice thing about using the two in a "hybrid" way is that if one of them is broken, the other can still protect the connection.

In TLS, the handshake establishes the session keys used to encrypt the rest of the connection. It’s this key exchange step that was the initial focus of experts.

After various tests, the hybrid group chosen (at least for starters) was X25519MLKEM768. Here, X25519 is the TLS key exchange method we use today. And MLKEM768 is the post-quantum part of the key exchange (Kyber).

Even if the new quantum-safe MLKEM768 method turns out to have a big weakness in it, then X25519 can still protect the session key, or at least against non-quantum computers. And if X25519 is broken (once Q-day has arrived), then MLKEM768 can still protect the session from being decrypted.

Harvest now, decrypt later

I have to do a small side story. Bear with me, it is relevant to all this. It also explains why we absolutely have to deal with post-quantum cryptography today (or preferably, yesterday) and not only care about PQC when good quantum computers are out there.

In June 2013, Edward Snowden revealed how big the mass surveillance programs were in the USA, UK and various other western countries. Wiretapping of internet traffic and gathering (meta)data at large scale. Much of the internet traffic was not encrypted in 2013 which made this easier.

Tech companies responded. For example, because links between Google's data centers were wiretapped they enabled encryption between them. Gmail would always use HTTPS. Google's Transparency Report started showing how much e-mail was sent encrypted and SMTP with STARTTLS was gaining more momentum. That was all within a year.

A few years later, around 2015/2016, Let's Encrypt launched their service. The idea for the project started in 2012 and after the Snowden reports in 2013, “the need for ubiquitous encryption [..] became clearer than ever". Thanks to Let's Encrypt everyone could get an SSL/TLS certificate for free, without much hassle. There was no excuse anymore not to use encryption.

We're more than 10 years later now and, if I dare to speculate, there's no reason to think that such government projects have stopped. To the contrary, they most likely have evolved and became bigger and better. Also, Snowden only talked about western countries. It again makes sense that other countries - including China - have similar programs and have improved theirs.

How is all this relevant you might ask? The thing is that, while encrypted data with SSL/TLS cannot be decrypted today, it can be stored for later use. With such mass surveillance programs, it makes sense to store large amounts of encrypted data. Then, when Q-day happens, all this stored historical encrypted data can be decrypted. That's what is called Harvest now, decrypt later. You can probably imagine this is of tremendous interest to governments. Surely, they won't store the traffic coming from Netflix. That would be too much. But e-mail traffic and of course certain "sites of interest", that certainly sounds doable to store. IRC traffic? Why not store that too? This all sounds perfectly doable and logical if you read how well funded those government programs were in 2013. Storage has only become cheaper since then.

Of course, at the same time, for those same governments, it is a huge threat to their own national security if an adversary can decrypt all confidential traffic. That's also why - at the same time - they publish guidelines, timelines and encourage a move to post-quantum crypto.

Protecting against "Harvest now, decrypt later"

So, tying those two stories together, the mass surveillance on one hand and the "hybrid" way of combining classic crypto with post-quantum crypto, shows how we can protect against Harvest now, decrypt later. By using something like X25519MLKEM768 today we can ensure web traffic, e-mail, conversations, and so on that happen today, remain protected even in a post-quantum world.

So how is the roll-out of X25519MLKEM768 going?

• Firefox 132.0 added it in October 2024.
• Chrome 131 enabled the finalized variant by default in November 2024 (after several years of experiments with a slightly different version).
• Safari on iOS 26 and macOS 26 enabled it in September 2025.
• On the server-side, Cloudflare deployed this in 2024, after earlier experiments in Oct 2022.
• OpenSSL is an important library used by many software (including UnrealIRCd). OpenSSL 3.5.0 added it and was released in April 2025.

Bringing PQC to IRC

In UnrealIRCd 6.2.0, released in Sep 2025, I added support for the X25519MLKEM768 algorithm. In UnrealIRCd we explicitly set the cipher suites and supported TLS groups, instead of leaving it up to the system. This has its pros and cons, but in any case I had to explicitly enable this. To actually benefit from this you would need OpenSSL 3.5.0 or later on the server, which - as said - was only released on April 2025.

As far as UnrealIRCd is concerned, these servers will automatically roll out with PQC in the next couple of years. Unfortunately we have this OpenSSL 3.5 requirement and this version is quite new in 2025. Debian had the fortunate timing that Debian 13 came out in August 2025, only a few months after the OpenSSL release. Ubuntu LTS will have to wait until Ubuntu 26.04 which will be released in April 2026 (the current Ubuntu 24.04 LTS ships with OpenSSL 3.0). Ubuntu is a big player, especially among people running UnrealIRCd, so I would expect PQC to gain a lot more traction in the second half of 2026.

Of course, IRC clients also need to support this. We rolled out X25519MLKEM768 on irc.unrealircd.org and we see a lot of use in websockets connections (so from webchats). That's because most browsers have support for this for more than a year. But for ordinary IRC client connections it is quite rare at the moment. I measure 18% on the UnrealIRCd network, which is probably on the high end since we have quite a lot of security conscious users. Most clients use OpenSSL and, again, this was only added in April 2025. There's a lot to be gained here.

The web PKI is still vulnerable

The web public key infrastructure, that SSL/TLS uses, relies on certificates and keys. Those still use classic crypto today (RSA/ECDSA). Such keys can be broken on Q-day, when a quantum computer with sufficient power exists, and then an attacker could impersonate the server. Fortunately we will likely have years until that day happens. And because we use X25519MLKEM768 in the TLS session key exchange, past traffic from the years before Q-day can't be decrypted. Also, such an attack would need to be active instead of just passive eavesdropping. I will likely make another blog post in the future about this.

Summary

This blog post explained how post-quantum cryptography is a threat today because of the Harvest now, decrypt later problem. We have learned how TLS sessions can be protected right now with X25519MLKEM768, how it protects a future quantum computer from decrypting old data. We've seen how browsers included this standard in 2024 and how we rolled it out in UnrealIRCd in 2025.

There's the remaining issue of RSA/ECDSA certificates/keys in the web PKI but there's still time to fix those in the next few years.

I like how the community chose a two-step approach to this problem. First, fixing the more urgent problem of Harvest now, decrypt later problem that was there. Then later, fixing the web PKI, which is not a problem yet right now.

Of course, all these protections don't make sense if you still have IRC with plaintext/unencrypted connections open on port 6667. That will be a topic for another blog post.