The Key Is the Route: Why Verimesh Runs on WireGuard

Many of us have spent more hours than we would like to admit watching people try to bring an IPsec tunnel up between two firewalls from different vendors. Anyone who lived through the VPN wars of the 2000s remembers the feeling: a config file with forty knobs, half of which had to match the other side exactly, and a debug log that told you nothing when they didn’t.

Then in 2018 a single developer, Jason Donenfeld, submitted WireGuard for inclusion in the Linux kernel, and Linus Torvalds, someone who famously tends to not mince his words, wrote that he could “only hope” it got merged soon, calling it “a work of art” next to the “horrors that are OpenVPN and IPSec.” That is high praise. It landed in mainline in 2020.

So when Palo Alto Networks, which sells the heavyweight security appliances WireGuard quietly makes look overbuilt, publishes a Cyberpedia explainer praising its small codebase, fixed modern cryptography and speed, that is worth a moment.

The encrypted mesh underneath Verimesh runs on WireGuard, and we do one thing on top of it that, as far as I know, nobody else does: the tunnel key derives from the same root as the application identity.

What Palo Alto is endorsing

WireGuard does not answer packets it cannot authenticate. Send a probe from an unknown key and you get nothing back: no banner, no response, not even a listening socket to fingerprint. To a port scan the mesh simply isn’t there, and you cannot attack a surface you cannot find.

Then there is the size of it. WireGuard is roughly 4,000 lines of code. OpenVPN is around 100,000. IPsec, counting its sprawl of standards and implementations, is closer to 400,000. A codebase you can read in an afternoon is one a human being can actually audit. And auditability at that scale is itself a security property, one you cannot retrofit onto something two orders of magnitude larger.

The cryptography is fixed. No configurable cipher suites, no algorithm negotiation, no “let’s downgrade to whatever we both support” step. Just Curve25519 for the key exchange, ChaCha20-Poly1305 for the data, BLAKE2s for hashing, Noise_IKpsk2 holding it together. The whole family of downgrade attacks does not exist here, because there is nothing to negotiate.

And WireGuard routes by key. Its cryptokey routing table binds each peer’s public key to the IP ranges that peer may use. Outbound, the destination address selects the peer’s key, which selects the session key; inbound, a decrypted packet is accepted only if its source falls inside that peer’s authorised range. There is no separate “who are you” check bolted on next to a “what may you send” check. The public key is the route. Identity and reachability turn out to be the same fact.

One root, not two

In nearly every WireGuard deployment I have seen, the keys live a life of their own. Someone runs wg genkey, hands out the public half, files the private half somewhere, and ends up with a network key that has nothing to do with the identity the application above it trusts. Two roots of trust reconciled by a spreadsheet and good intentions.

In Verimesh there is one root. Each organisation’s Curve25519 tunnel keys are anchored in its own Decentralized Key Management (DKMS) material. The same identity infrastructure the application layer already runs on. Nobody issues them. There is no certificate authority in the path deciding which tunnels are permitted, and no gap between who you are at the network layer and who you are above it.

Because the keys trace back to the organisation’s own key material, every tunnel can be checked against the key event log: you can ask which identity brought up which tunnel and when, and verify the answer cryptographically rather than trusting a server’s own account of itself. When keys rotate, they rotate in step with DKMS pre-rotation (built on KERI), so the tunnel identity survives the key lifecycle instead of snapping when a key changes. And since the whole thing is self-hosted, no intermediary sits in the middle owning the data flow.

So why not just use mTLS, which already binds identity into the transport handshake?

Because keeping the layers apart is the point. WireGuard moves authenticated, encrypted packets between peers that hold the right key, and then it stops. It does not know what a consent withdrawal is, which authorisation a message carries, or whether a credential has been revoked. That logic belongs above the wire, in DKMS. mTLS tends to pull authorisation down into the transport handshake until you can no longer audit the two separately. We keep them apart on purpose, and build them on the same root.

Sovereign down to the wire

The stack is Open Source from top to bottom. WireGuard is in the kernel; the DKMS layer above it is ours, published under the AGPLv3. No SaaS control plane sits in the path. No third party who can be subpoenaed for the keys, nobody quietly logging who talked to whom. For Swiss healthcare, where the data may not leave the country and the trust may not leave the institution, that has to hold down to the transport. Sovereignty that stops at the application layer and rents its network plumbing from someone else is not really sovereignty.

What we are trading away

No architecture is free, and the people who run these systems can smell it when you pretend otherwise. WireGuard asks for three trades, which we are transparent about:

First, it is a layer-3 tunnel. It carries IP packets, not streams, so you do not get the native stream multiplexing a TLS- or QUIC-based transport hands you for free. Anything that needs multiplexing builds it above the tunnel. For a mesh carrying authenticated exchange between institutions that is arguably the right place for it, but it is a real constraint, not a non-issue.

Second, the peer configuration surface grows with the mesh. WireGuard ships no control plane that hands out and revokes peers centrally; each node knows the peers it talks to. In a small, governed mesh of hubs and nodes that is a feature. Nothing central to compromise. At large scale it becomes real work, and administrating the keys via DKMS is what keeps it from collapsing into the spreadsheet nightmare from earlier.

Third, it is younger than IPsec. Palo Alto puts this on the cons list and that makes sense. But the thing that makes WireGuard young is the same thing that makes it auditable: Donenfeld threw away three decades of accumulated optionality and started over. This is the kind of trade we make gladly.

The quantum question

WireGuard has an optional pre-shared-key layer that mixes a symmetric secret into the handshake. That buys one thing: traffic captured today does not become readable later even if the elliptic-curve exchange is eventually broken. The store-now-decrypt-later attack stops working. This is not the same as post-quantum security in the NIST sense, and we are aware of that. It is an effective hedge.

The route past the hedge has a name: Rosenpass, an Open Source project that runs a genuine post-quantum key exchange in front of that pre-shared-key slot. It is an integration path for the mesh, not something Verimesh ships today.

What is ours is what happens next. Because the tunnel keys derive from DKMS, adopting post-quantum algorithms is a routine key rotation on the existing key event log. Not a forced, all-at-once certificate reissuance across an entire estate. CA-issued transport does not get to say that.

One root, from the wire up

A mesh where the network key and the application identity grow from the same DKMS material closes the seam where most of the interesting attacks and nearly all of the boring audit failures live: the gap between who the network thinks you are and who the application thinks you are. WireGuard gives us a transport simple enough to trust; DKMS gives it the same identity everything else in Verimesh already trusts.

This is the transport underneath the Verimesh rollout with HIN, beneath everything in the Trust Architecture, where the full path from key to tunnel to audited message is laid out end to end. What runs on top is Verimesh itself.

Good plumbing is the kind you never have to think about. That is the whole idea.