# Rosenpass: post-quantum key exchange for WireGuard

> Rosenpass adds post-quantum key agreement to WireGuard by refreshing a symmetric preshared key and passing it through WireGuard's PSK feature. The Rust project includes both the protocol implementation and the privileged `rp` integration frontend, with a separate container-oriented mode for tighter privilege separation.

**rosenpass/rosenpass** — Rosenpass is a post-quantum-secure VPN that uses WireGuard to transport the actual data. 

- Repository: https://github.com/rosenpass/rosenpass
- Website: https://rosenpass.eu
- Stars: 1,442 · Forks: 137
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/rosenpass-rosenpass

## What Rosenpass Changes in a WireGuard Deployment

Rosenpass addresses the key agreement problem in a VPN deployment. WireGuard carries the VPN traffic, while Rosenpass establishes and periodically replaces the symmetric key used for that connection. The repository describes Rosenpass as post-quantum secure, but that claim applies to its key establishment layer rather than turning WireGuard into an unrelated transport. WireGuard remains responsible for moving the actual data.

The intended audience is operators who already understand WireGuard or want the repository's `rp` frontend to manage both systems as one VPN. Rosenpass may also suit applications that need its protocol output but do not use the integrated frontend. The standalone implementation can write keys to files, which creates an integration point for another VPN tool, but that arrangement requires additional configuration and operational work.

Rosenpass supplies its symmetric key through WireGuard's PSK feature. The README characterizes this as hybrid security: the connection derives protection from both Rosenpass and WireGuard rather than being cryptographically weaker than ordinary WireGuard alone. That mechanism is central to the project. It does not replace packet encryption, peer configuration, routing, or interface management supplied by WireGuard.

## The Rosenpass Key Refresh and WireGuard PSK Path

The main `rosenpass` tool is written in Rust and uses `liboqs`. Based on the repository description, it establishes a symmetric key and passes that key to WireGuard through the PSK feature. The key is refreshed every two minutes. This repeated update is the principal data flow between the two components: Rosenpass manages the agreement and refresh, while WireGuard uses the resulting value as part of its established connection.

The separate `rp` frontend is also written in Rust. It is intended to make WireGuard and Rosenpass easier to deploy together, but it introduces operational responsibilities that the standalone mode does not. The README states that `rp` runs as root, requires access to both WireGuard and Rosenpass private keys, takes control of the interface, and works with exactly one interface. Those are concrete adoption constraints for a machine that already has other VPN interfaces or sensitive key material.

Rosenpass does not enforce a client and server separation in the manner of a user-oriented VPN service. Omitting `listen` selects client mode and allows the tools to choose random ports. Omitting `endpoint` selects server mode, so Rosenpass waits for peers instead of initiating a connection. Both options can be specified. The README says that omitting both is allowed but not useful, which is a useful indication that deployment mode must be selected deliberately.

## Ports, Modes, and the Two-Process UDP Arrangement

The `rp` frontend allocates two UDP ports. If port N is assigned to Rosenpass, the frontend assigns port N+1 to WireGuard. This fixed relationship is important when placing the pair behind a firewall or configuring a peer. The README does not provide a complete firewall example, so operators must translate the documented port rule into their own network policy.

Client mode is selected when `listen` is not specified. In that case, Rosenpass and WireGuard choose random ports. Server mode is selected when `endpoint` is not specified, causing Rosenpass to wait for incoming peer connections. The documentation allows both settings to be present, which supports a peer that listens and also has a known destination. It does not document a built-in mechanism for separating ordinary clients from servers, so network policy and endpoint management remain the operator's responsibility.

The random-port behavior deserves attention when a remote peer must reach the host. A server deployment needs predictable reachability, while client mode is more convenient when the peer connects outward. The README gives the mode rules but does not provide a full NAT traversal or roaming recipe in the excerpt, so those cases should not be inferred from the project name or general WireGuard knowledge.

## Installing Rosenpass and Starting With the Help Commands

The README points installation users to the Rosenpass website rather than giving one package-manager command. It says the software is packaged for an increasing number of distributions and links to the installation guides at `https://rosenpass.eu/docs`. The exact distribution package and installation command therefore depend on the host and are not specified in the repository excerpt.

After installation, the documented first check is the help output for both the frontend and the protocol tool:

```sh
rp help
rosenpass help
```

These commands confirm that both binaries are available and expose their supported options. The README then directs users to the quick start instructions on the Rosenpass website to bring up a VPN.

For a first deployment, read the quick start guide before placing credentials in an `rp` configuration. Decide whether the host should use client mode or server mode, account for ports N and N+1, and confirm that the selected integration approach can expose the required private keys and network interface.

## Why `rp` Is Easier but Less Separated

The `rp` frontend is the convenient path for combining Rosenpass and WireGuard. According to the README, it manages a VPN with the two tools and reduces the amount of manual integration. That convenience comes with a clear security and operational cost: it runs as root, sees both private keys, controls the interface, and handles one interface only.

The standalone mode is the documented alternative for operators who do not want to grant `rp` that access. Rosenpass can write keys to files, and the README says that scripting can run the application in a container, virtual machine, or another host. This arrangement can put key access and process privileges into separate boundaries. The README uses the phrase "more secure setup" in this context, but it does not provide a complete container or jail recipe, so the actual boundary depends on the deployment.

Standalone mode also broadens the integration surface. Another tool can consume Rosenpass output instead of WireGuard, provided the operator supplies the required plumbing. That is useful when WireGuard's interface model is not the target, yet it transfers more responsibility to scripts and configuration. The choice is therefore between the frontend's integration and its privileged access, or a custom boundary with additional maintenance.

## Protocol Analysis, Distribution, and Upgrade Surface

The repository includes a ProVerif symbolic analysis of the Rosenpass protocol. The README says that a cryptographic proof of security is in progress, so the available analysis should not be described as a completed formal proof of all stated properties. The supplied commands are:

```sh
(nix) $ nix build .#proof-proverif --print-build-logs
(manual) $ ./analyze.sh
```

The manual route requires `proverif`, `graphviz`, `awk`, and `cpp`. The repository describes the analysis as split across files and entry points, with parallel analysis and a wrapper that reports expected query results. This is useful for contributors reviewing the protocol model, but it is separate from operating a VPN.

The repository publishes `ghcr.io/rosenpass/rosenpass` and `ghcr.io/rosenpass/rp` Docker images. The README links to container usage documentation. Recent releases listed for the project are `v0.2.3` on 2026-08-03, `v0.2.2` on 2024-06-05, and `v0.2.1` on 2023-11-18. The last push was on 2026-10-15. That recency is a repository fact, not a guarantee that a deployment has low upgrade cost. Upgrading may affect the daemon, frontend, WireGuard integration, configuration format, and cryptographic dependencies.

The project is licensed under Apache-2.0, with a repository entry for `LICENSE-APACHE`. That identifies the stated license for review purposes; it does not answer questions about compatibility with a particular product, distribution, or deployment.

## Conclusion

Operators who want a documented post-quantum key exchange around WireGuard can adopt Rosenpass after checking the installation guide for their distribution, reviewing the required key exposure, and deciding whether `rp`'s root privileges are acceptable. Projects that only need conventional WireGuard, or cannot accept the additional daemon, keys, ports, and refresh process, should stay with standard WireGuard. The first concrete decision is whether the standalone mode provides the required privilege separation.

## FAQ

### Does Rosenpass replace WireGuard?

No. The README describes Rosenpass as a post-quantum-secure VPN layer that uses WireGuard to transport the actual data. Rosenpass establishes and refreshes a symmetric key, then supplies it through WireGuard's PSK feature.

### How often does Rosenpass refresh its symmetric key?

The repository states that Rosenpass refreshes the symmetric key every two minutes. WireGuard uses the resulting key through its PSK feature.

### What privileges does the `rp` frontend need?

The README says `rp` runs as root, requires access to both WireGuard and Rosenpass private keys, takes control of the interface, and works with exactly one interface. The standalone mode is documented as an alternative for deployments using containers, jails, or virtual machines.

## Sources

- [License: Apache-2.0](https://github.com/rosenpass/rosenpass/blob/main/LICENSE)
- [Project website](https://rosenpass.eu)
- [README](https://github.com/rosenpass/rosenpass/blob/main/README.md)
- [Releases](https://github.com/rosenpass/rosenpass/releases)
- [rosenpass/rosenpass on GitHub](https://github.com/rosenpass/rosenpass)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rosenpass-rosenpass