Are you aware that even in the absence of quantum computers today, the encrypted data in your organization or personal information remains vulnerable? This might not be an immediate concern, but it's a ticking time bomb. Cybercriminals are already capable of harvesting encrypted data with the intent to decrypt it later. Once quantum computing becomes widely accessible, these hackers will have the tools to retroactively decrypt previously secure information.

NetBird is deeply committed to network security, enabling organizations to protect their networks through point-to-point connection encryption, micro-segmentation, and comprehensive network visibility. While these measures are effective against today's threats, what about future security challenges of the post-quantum world? In the past few months, we've spent some time on this topic, experimenting and integrating Rosenpass, a key exchange protocol that uses secure techniques against attacks from quantum computers.

Even though this feature is experimental, we believe we have created the first quantum-resistant mesh-capable VPN. Are you interested in learning how it works and trying it for yourself? Please read on, and traditionally, you can always check our code; it is open source.

The need for quantum-resistant cryptography

Today's encryption methods will be at risk when quantum computers arrive. There's no set date, but experts think we might see the first quantum computers between 2035 and 2040. These computers will likely be able to decrypt nearly all the encrypted data being shared on the internet right now.

What's the immediate risk? As highlighted in the introduction, malicious actors could adopt a "harvest now, decrypt later" strategy. This involves intercepting and storing encrypted data, for example, network traffic, with the intent to decrypt it in the future once quantum computing technology becomes available.

Consider a hospital with sensitive patient records or a financial institution storing confidential customer data. These organizations have numerous data pathways between internal applications and databases where a hacker can tap in and steal data. Additionally, these organizations often have hundreds, if not thousands, of employees, accessing this information from various devices, often remotely, increasing the attack surface. While several security measures can be put in place—such as multi-factor authentication (MFA), the principle of least privilege access, and mutual authentication—to mitigate risks and safeguard this data, it's important to accept that absolute security is unattainable in cybersecurity.

No wonder being a CISO is stressful, and quantum computers do not bring more excitement to their job.

So, what can we do to help CISOs and security professionals of the world sleep better at night? Well, at least we could bring some order (and hopefully excitement) to their private networks and protect the traffic from the future threat—quantum computers.

If you are not a CISO looking to release stress but happen to use or be familiar with WireGuard, stay with me, as we have some exciting solutions involving Rosenpass that uses WireGuard's pre-shared keys.

Using pre-shared keys in WireGuard

If you've heard about WireGuard, you've probably also heard about an option to use pre-shared symmetric keys. Using pre-shared keys in WireGuard is optional, but it helps mitigate future quantum computer attacks with an additional layer of symmetric encryption. To enable this option, one needs to pre-share a 256-bit symmetric encryption key between any pair of WireGuard peers.

We can use the command to generate a pre-shared key :

We can now set this key on a pair of WireGuard peers and see what happens. I will be using the command to configure peers. One peer is my Ubuntu 22.04 laptop, and the other is a remote server on Digital Ocean, also running Ubuntu 22.04.

Equipped with ChatGPT, I generated the following WireGuard configs. One for the remote server:

The other one for my laptop which will be the client:

Please do not use these configuration files in production, as publicly exposed keys would compromise any system they're used in. Also, don't forget to set a proper on your client configuration.

By the way, NetBird is a point-to-point private network that automatically configures WireGuard, so you don't need to worry about copying and pasting configuration files, public IPs, and key distribution as it is done from a central place - the NetBird Management service. Later in this post, you will see how the "zero configuration" effect also applies to enabling post-quantum resistance in your private network.

Now, back to our WireGuard setup. After Running on both machines and pinging the server from my laptop, we can confirm that the machines connected successfully:

We can also see what pre-shared keys are used by running the following command:

That was pretty straightforward. But there is a challenge, though. How can we generate and securely exchange pre-shared keys between peers automatically? This is where Rosenpass steps in.

About Rosenpass

Rosenpass is a key exchange protocol using techniques that are secure against attacks from quantum computers. It employs two strong post-quantum key exchange methods – Classic McEliece and Kyber. The latter has been selected in the NIST post-quantum cryptography competition to become a post-quantum cryptographic standard.

The Rosenpass application runs side-by-side with WireGuard and generates a new post-quantum-secure pre-shared key (PSK) every two minutes. The generated pre-shared key can then be applied to WireGuard, which still performs the pre-quantum-secure key exchange and transfers any transport data without involvement from Rosenpass. Check the Rosenpass protocol whitepaper for more details on how it works.

Running WireGuard with Rosenpass

Let's get into some cool stuff. We will now try running Rosenpass and see how to use generated pre-shared keys in WireGuard.

Similar to setting up WireGuard, the Rosenpass daemons on both machines must be configured to recognize one another. This involves exchanging Rosenpass public keys and ensuring that each daemon knows the public endpoints of the other, enabling them to establish a connection. Wait! Is there another config on top of the one we already have for WireGuard? Yes, but don't worry. Later in the article, I will show you how Rosenpass integrates with NetBird, where you don't need to worry about configuration.

First, we will need to download and install Rosenpass:

Second, we will generate a pair of private and public keys for Rosenpass and do some configuration.

On the client machine:

On the server machine:

Like with WireGuard, we will need to make the Rosenpass server and client aware of each others public keys. Thus, we should copy the file from the server to the client and the from the client to the server.

After copying the keys, we can run Rosenpass daemons using the command. On the client machine:

On the server machine:

Please note that I configured the property on the client machine to specify the server's remote address as . Ensure you replace with your server's public IP address. The port is the Rosenpass listen port. The following output on both machines indicates that Rosenpass successfully generated a new WireGuard pre-shared key:

Both client and server Rosenpass instances stored a newly negotiated symmetric key in the file we specified in the property. Rosenpass will update this file every two minutes to rotate the key.

We can now use this key and apply it to the WireGuard instances we configured by running the command on both machines:

and

Let's verify if we applied the keys correctly:

One crucial detail is that even if you applied a pre-shared key only on one of the machines, the connection would still work for a few minutes. Why? This is due to the WireGuard's handshake mechanism. When you first apply the PSK on one machine and not the other, the existing session (established before the PSK configuration) continues to work until the next handshake attempt. This behavior can lead to a situation where traffic continues to flow for a short period, even after a configuration mismatch. WireGuard will continue to use the last successful handshake until a new one happens.

How scalable is this?

Let's summarize the setup. Rosenpass operates separately from WireGuard, running as an independent application on its own port on both machines. Like setting up WireGuard, you need to configure Rosenpass with its public keys. Additionally, one Rosenpass instance must be set up with the remote's public endpoint to enable key exchange. Rosenpass generates a new pre-shared key (PSK) every two minutes, which you then manually apply to the WireGuard interface on both machines. Voilà, and you have a quantum-resistant WireGuard-based VPN.

I know what you are thinking. This doesn't scale, right? How about a production setup with hundreds of machines? Pre-sharing additional symmetric keys is an excellent idea but can be troublesome from a key management perspective. Add that many machines are behind NATs and change their public IPs frequently, and you will end up with a configuration hell. How do we simplify the process without compromising on quantum resistance? We asked ourselves at NetBird, and here is the solution.

Setting up a quantum-resistant mesh VPN

This is the only thing you need to do to enable post-quantum resistance in your private network. There is no need to configure WireGuard or Rosenpass. NetBird will automatically establish a point-to-point WireGuard connection between all your machines and enable Rosenpass on top of it. Of course, given that you have NetBird installed on your machines.

To prove this statement, I will run the command on my laptop:

And on the server:

After SSO and MFA authentication, we can see that the pre-shared keys are being generated and applied to the WireGuard interfaces every two minutes:

I can even ping my laptop from the server "with quantum-resistance" by using a search or fully qualified domain name (FQDN) that NetBird automatically assigned to it:

I will add another machine to the network to make it even more interesting and run NetBird as a docker container on my laptop. I will need to generate a one-off setup key, as there is no way to do an interactive login with SSO in a container:

As a result, NetBird forms a small three-node mesh network where machines connect directly to each other. Running the command on my laptop indicates that there are now two WireGuard peers with the enabled pre-shared keys:

Add as many machines as you want; try it on AWS Lambda or Azure Functions to add some serverless flavor to your mini-mesh network.

For the especially curious, here is the Rosenpass integration PR on GitHub that we merged into main recently: netbirdio/netbird#1153.

Conclusion

I want to use this section not to say how vital network security is and that modern cryptography is under threat when quantum computers will hit the mass market. But to credit the creators and developers of the beautiful open-source technologies we use at NetBird. Some of these people I'm lucky to know personally. Thank you, Jason A. Donenfeld for WireGuard, Karolin Varner & Team for Rosenpass, and Steffen Vogel for rosenpass-go.

By no means do we consider ourselves post-quantum cryptography experts. This post aims to raise awareness about future security threats, trigger discussions, and inspire others to open source their solutions and experiment with post-quantum cryptography. However, we educated ourselves on the topic. We consulted with people working in the field to understand the basics to be able to carry out the experiment and share the results with you.

If you want to lear more about the implementation details, check out this post: How We Integrated Rosenpass in NetBird.