PQConnect #

Late last year I came across a post on X by Daniel J. Bernstein announcing something called PQConnect. In brief it is software you can install on Linux that will create a post-quantum secure tunnel between clients and servers with this software installed. Post-quantum meaning cryptography that should be secure when powerful quantum computers that can break existing, traditional cryptography becomes available.

This isn’t something I think I need, but I find it interesting and wanted to experiment with it.

As mentioned, only Linux is supported today, but this was just released so I’m sure support for more platforms will come later. I’d like to see it supported on the BSDs I use, OpenBSD and FreeBSD as well, and hopefully in a ready to use package. Installing today consists of downloading a .tar.gz file, unpacking and running an install script, which in turn downloads more files. It is based on python, but it’s not clear to me what it installs and where, so if I want to remove this at some point, I’m not sure how to go about it.

Another downside is that you would need to change your DNS setup by creating an entry with a hash PQConnect generates, like this:

pq14ada0dcc8ebbb178ef954d6d48f108d83d78b3510cdaf79de7655b4c64da4240.example.com

Then you would need to point your webserver like www.example.com to this entry as a CNAME. And I guess it means it’s not possible to access just example.com in the browser through PQConnect, since the domain itself can’t be a CNAME.

Another downside is that you need to set up your firewall to intercept DNS requests, so they go to the PQConnect client first, and if it finds the hash it will connect to the PQConnect server through the tunnel with a private address in the 10.43.0.0/24 range.

Then whoever connects to your services through PQConnect will be seen as comming from this private 10.43 address, meaning it will be more difficult to identify and block abusers.

Hopefully an option to still get the connecting public ip of the client will become available in the future.

Rosenpass #

What I found to be more interesting, was that the PQConnect page mentioned some other software that supports post-quantum secure encryption, one of them being Rosenpass.

Rosenpass works by establishing a post-quantum secure tunnel between two hosts, and then uses that tunnel to transmit a pre-shared key. This key is then added to the Wireguard interfaces on both sides, thereby increasing the security of the Wireguard tunnel. The key is replaced every two minutes, meaning if someone was able to crack the standard Wireguard encryption and get a hold of a pre- shared key, they should only be able to decrypt about 2 minutes worth of data. Since the key exchange happens outside of Wireguard they should not be able to get the next key generated. This is the problem with transferring a pre-shared key through an existing Wireguard tunnel, if that was cracked they would be able to get the next key as well, and keep decrypting the data.

Again this is something I probably don’t need, but since I have a small Wireguard network, I thought I would try to implement it to experiment with and learn about. Rosenpass is only at version 0.2.2 so it’s not production ready yet, and I did indeed encouter a few issues. Not to mention it became a little more tricky to get the firewalls set up properly and have traffic flowing through as it should. I probably made a mess of everything since I kept my existing Wireguard network as it was, and then added another network for Rosenpass. Using the rp helper tool that comes with Rosenpass, it automatically creates a new wireguard interface called rosenpass which is the one it protects by changing the pre-shared key. Another thing here is if the Rosenpass key exchange uses port 10000, the new interface will use port 10001, and this is not configurable.

Then there were issues with listening on the correct interface, as well as traffic direction, who connects to who?

And so time flies.

A general downside to Wireguard I think, is that if you have not been able to generate and/or distribute the public keys correctly, packets will be silently dropped. While nice in that it doesn’t advertise that there is a service listening on the port, it makes it a little hard to debug. Does traffic not go through because of a network or firewall issue, or is the problem with the keys? Then with the config you don’t work with hostnames, but with hashes, as seen in my Wireguard post, and you don’t connect to hostnames either, but IP addresses. All of which makes it a little easy to make a mistake when configuring this.

I feel I have learnt a lot through my trial and error though, so maybe I’ll come back and detail my setup later.