Post-Quantum Cryptography in Tor's TLS Layer: Help needed!
Hello Tor Relay Operators, With the arrival of OpenSSL 3.5.0 in 2025, we finally had an important missing piece of infrastructure to start enabling the Tor network to support Post-Quantum Cryptography in the outermost cryptographic layer of the Tor protocol. Since Tor version 0.4.8.17, we have supported the x25519/ML-KEM-768 hybrid handshake in our TLS layer, and we have gradually seen more relays supporting it in the production network. Tor Browser has been built against OpenSSL >= 3.5.0 since (at least) version 13.5.22, released in September 2025, and therefore supports Post-Quantum TLS handshakes today, but it requires that its guard node supports it. We need to give a big shout-out to the OpenSSL Team here to get this out and available to the masses! <3 Since Q3 2025, I've been running some semi-regular scans of the Tor production network to check for TLS cipher suite availability. This work started as part of the first Tor Community Gathering back in October, 2025[1]. The results are as follows: In January, around 28% of the Tor relays supported the Post-Quantum TLS handshake. The scan I did yesterday showed an increase of around 4 percentage points to 32.32%. Out of 9476 scanned relays, 9185 were reachable, 291 were unreachable. Of the 9185 reachable relays, I saw the following distribution of cipher suites: `TLS13_AES_256_GCM_SHA384`: 9023 relays. `TLS13_CHACHA20_POLY1305_SHA256`: 158 relays. `TLS13_AES_128_GCM_SHA256`: 4 relays. For the key exchange groups, I saw the following distribution: `secp256r1`: 6212 relays. `X25519MLKEM768`: 2969 relays. `X25519`: 4 relays. Of the Directory Authorities, 5 of them supported the `X25519MLKEM768` key exchange group during the TLS handshakes. 2969 / 9185 * 100 = 32.32% of relays support the `X25519MLKEM768` cipher suite. This number is a good start, but we should ideally bump it up! You can see the individual results for your relay(s) in the big table available at https://ahf.me/tor-tls-pqc/2026-02-26/ -- entries without a cipher suite or key exchange group were unreachable at the time I ran the scan. These missing entries can be due to a network problem anywhere on the path between my host and yours, so don't get worried if your relay is missing :-) The scanner I used is free software and is available as part of the Network Health Team's Margot tool[2], used for various analysis purposes. Please note that the goal here isn't to enumerate all available cipher suites for each relay, but instead I'm interested in the "strongest" possible cipher suite my custom client can negotiate with each relay. My ask for you as the relay operator community here is as follows: Next time you folks are doing maintenance on your relay(s), please have a look at whether you can upgrade either your packages or underlying software distribution to a version such that you either get a new enough version of OpenSSL (>= 3.5.0), or if you are a LibreSSL user, check whether the LibreSSL project supports the ML-KEM hybrid handshake, and upgrade to that version. It looks like the LibreSSL project is currently working towards supporting the ML-KEM handshake in the next upcoming release[3]. For Debian users, to get a new enough OpenSSL version that supports the PQC TLS handshake, you need to upgrade to (at least) Debian Trixie. For everybody else, it's best to check your respective software distribution's package management system to find the version you need to upgrade to. For Arti users, a licensing issue with the currently available crypto providers in Arti prevented enabling the ML-KEM handshake. Nick, however, has recently been making progress on this matter and has a patch up that is now pending upstream review[4]! :-) If you are excited about exploring different aspects of the Tor ecosystem, talking with other Tor enthusiasts, and you have nothing planned for your weekend in two weeks, I highly encourage you to look into the next Tor Community Gathering in Denmark. The event takes place from 2026-03-13 to 2026-03-15. For more information, check out our website at https://onionize.space/2026/ Thank you all for all the work you do to make Tor better! <3 Cheers, Alex [1]: https://onionize.space/2025/ [2]: https://gitlab.torproject.org/tpo/network-health/margot/ [3]: https://github.com/libressl/portable/blob/a989b7acb9a475fde656e48dbcb38289de... [4]: https://github.com/RustCrypto/rustls-rustcrypto/pull/143 -- Alexander Hansen Færøy
Hey Thanks for the excellent work.
Out of 9476 scanned relays, ... , 291 were unreachable.
An interesting number for two reasons: i. Mine are in that group of unreachable relays, still :( Going to bump to Libressl 4.3.0 as soon as it is available :) - and functional. ii. Is it fair to suggest that a max of 291 relays use Libressl out of the 9476 being scanned? Besides Libressl is later than Openssl, how do we look at this proportion, is it worth to increase the slice? Cheers
On Fri, 27 Feb 2026, Alexander Hansen Færøy via tor-relays wrote:
My ask for you as the relay operator community here is as follows: Next time you folks are doing maintenance on your relay(s), please have a look at whether you can upgrade either your packages or underlying software
The tor package for FreeBSD appears to support this, nice! $ grep -e OpenSSL -e TLS /tmp/tor_notices.log [notice] We compiled with OpenSSL 30500040: OpenSSL 3.5.4 30 Sep 2025 and we are running with OpenSSL 30500040: 3.5.4. These two versions should be binary compatible. [notice] Tor 0.4.8.21 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL 3.5.4, Zlib 1.3.1, Liblzma 5.8.1, Libzstd 1.5.7 and BSD 1500068 as libc. [notice] Set list of supported TLS groups to: ?*X25519MLKEM768 / ?SecP256r1MLKEM768 / *P-256:?X25519:P-224 Thank you for your efforts here, this is really cool! Christian. -- BOFH excuse #217: The MGs ran out of gas.
Hey Felix, On 01/03/2026 11.12, Felix via tor-relays wrote:
Hey
Thanks for the excellent work.
Out of 9476 scanned relays, ... , 291 were unreachable.
An interesting number for two reasons:
i. Mine are in that group of unreachable relays, still :( Going to bump to Libressl 4.3.0 as soon as it is available :) - and functional.
ii. Is it fair to suggest that a max of 291 relays use Libressl out of the 9476 being scanned? Besides Libressl is later than Openssl, how do we look at this proportion, is it worth to increase the slice?
Yesterday, when I tried to reply to your email, I wrote a longer message about how the 291 number roughly matches what I saw in my earlier scan in January (~198 relays that were unreachable). While writing the mail, I tried to reproduce the result by only scanning George's Serge Bridge Authority relay, which I know is OpenBSD with LibreSSL, but I was unable to reach it at all. It turns out you likely found a bug in our new PQC handshake code! When I use the initial version of the scanner, which uses another crypto provider for the PQC, it works! We'll get this fixed, but this issue also made me run a new full network scan with the old crypto provider here. This scan had no errors from the TLS layer. The results are available at https://ahf.me/tor-tls-pqc/2026-03-01/ Good catch here, Felix! With regard to whether it's a good idea to have a larger proportion of the network based on LibreSSL, I will fall back on my usual thought on the network diversity question, which is that operators should use what they are most comfortable with :-) The summary of yesterday's scan is as follows: Scan Stats: - 9562 relays were reachable. - 158 relays were unreachable. Cipher Suites: - `TLS13_AES_256_GCM_SHA384`: 9352. - `TLS13_CHACHA20_POLY1305_SHA256`: 165. - `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`: 39. - `TLS13_AES_128_GCM_SHA256`: 6. Key Exchange Groups: - `X25519`: 5350. - `X25519MLKEM768`: 3313. - `secp256r1`: 899. Directory Authorities: - 10 out of 10 were reachable. - `TLS13_AES_256_GCM_SHA384` was used by all 10. - `X25519` was used by 5, and `X25519MLKEM768` was used by 5. 3313 / 9562 * 100.0 = 34.65% of relays are supporting the `X25519MLKEM768` PQC handshake in the network right now. Again, thanks for catching this, Felix! Cheers, Alex -- Alexander Hansen Færøy
Hello Tor Relay Operators! I did a scan of the network again yesterday. Here're the numbers that you can compare against our numbers from March: Scan Stats: - 9707 relays were reachable. - 106 relays were unreachable. Cipher Suites: - `TLS13_AES_256_GCM_SHA384`: 9517. - `TLS13_CHACHA20_POLY1305_SHA256`: 155. - `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`: 32. - `TLS13_AES_128_GCM_SHA256`: 3. Key Exchange Groups: - `X25519`: 4827. - `X25519MLKEM768`: 4326. - `secp256r1`: 554. Directory Authorities: - 10 out of 10 were reachable. - `TLS13_AES_256_GCM_SHA384` was used by all 10. - `X25519` was used by 5, and `X25519MLKEM768` was used by 5. 4326 / 9707 * 100 = 44.57% of the relays support PQC handshakes right now. It's great to see that we have over 1000 more relays supporting PQC, but we are still a bit away from being able to enforce PQC in any possible manner here. I've updated the list of relays and what they support here: https://ahf.me/tor-tls-pqc/2026-06-18/ If your relay does not yet support the `X25519MLKEM768` group, it would be really lovely if you could look into upgrading your TLS library (OpenSSL >= 3.5.0 and LibreSSL >= 4.3.0) used by your relay. Thanks all for running relays! <3 Cheers, Alex On 02/03/2026 14.29, Alexander Hansen Færøy via tor-relays wrote:
The summary of yesterday's scan is as follows:
Scan Stats: - 9562 relays were reachable. - 158 relays were unreachable.
Cipher Suites: - `TLS13_AES_256_GCM_SHA384`: 9352. - `TLS13_CHACHA20_POLY1305_SHA256`: 165. - `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`: 39. - `TLS13_AES_128_GCM_SHA256`: 6.
Key Exchange Groups: - `X25519`: 5350. - `X25519MLKEM768`: 3313. - `secp256r1`: 899.
Directory Authorities: - 10 out of 10 were reachable. - `TLS13_AES_256_GCM_SHA384` was used by all 10. - `X25519` was used by 5, and `X25519MLKEM768` was used by 5.
3313 / 9562 * 100.0 = 34.65% of relays are supporting the `X25519MLKEM768` PQC handshake in the network right now.
-- Alexander Hansen Færøy
Hi Alex
Key Exchange Groups: - `X25519`: 4827. - `X25519MLKEM768`: 4326. - `secp256r1`: 554.
Directory Authorities: - 10 out of 10 were reachable. - `TLS13_AES_256_GCM_SHA384` was used by all 10. - `X25519` was used by 5, and `X25519MLKEM768` was used by 5.
4326 / 9707 * 100 = 44.57% of the relays support PQC handshakes right now.
If your relay does not yet support the `X25519MLKEM768` group, it would be really lovely if you could look into upgrading your TLS library (OpenSSL >= 3.5.0 and LibreSSL >= 4.3.0) used by your relay.
The relays are since May 08 22:38:42.281 [notice] Tor 0.4.9.8 running on FreeBSD with ... OpenSSL LibreSSL 4.3.1, ... since Jun 02 19:17:27.354 [notice] Tor 0.4.9.9 running on FreeBSD with ... OpenSSL LibreSSL 4.3.1, ... but are still listed without PQC. What should log notice state for a correct PQC key exchange? Or am I missing something? Cheers!
On 19/06/2026 16.04, Felix wrote:
The relays are
since May 08 22:38:42.281 [notice] Tor 0.4.9.8 running on FreeBSD with ... OpenSSL LibreSSL 4.3.1, ...
since Jun 02 19:17:27.354 [notice] Tor 0.4.9.9 running on FreeBSD with ... OpenSSL LibreSSL 4.3.1, ...
but are still listed without PQC.
What should log notice state for a correct PQC key exchange? Or am I missing something?
Hey Felix, Nope. We in the Network Team need to fix this. It's an issue in Tor. I opened https://gitlab.torproject.org/tpo/core/tor/-/work_items/41300 yesterday with this specific problem after I had sent out the email to the list. This is sadly one of those situations where a slight divergence between LibreSSL and OpenSSL, which will naturally occur over time, has an impact on us. We'll get this fixed in one of the upcoming C Tor releases! Cheers, Alex -- Alexander Hansen Færøy
participants (3)
-
Alexander Hansen Færøy -
Christian Kujau -
Felix