In twenty fifteen, a security researcher named Jason Donenfeld was building a rootkit. Not because he was a criminal, but because that was his job. Donenfeld ran a company called Edge Security, and part of penetration testing is building tools that can hide inside a system without being detected. A good rootkit needs a stealthy communication channel, a way to send data back to the tester without network monitoring tools noticing.
Donenfeld needed that channel to be invisible to packet inspection, fast enough to not add suspicious latency, and cryptographically solid. He looked at the existing options for encrypted tunnels: IPSec and OpenVPN. Both were well established. Both were, in his professional opinion, terrible. Not terrible as in they did not work, but terrible as in they were so complex that complexity itself became a security risk.
OpenVPN's codebase was around seventy thousand lines of code. IPSec was worse, scattered across hundreds of thousands of lines when you counted all the implementations and configuration layers. These were systems that had grown organically over decades, accumulating features, options, cryptographic suites, and compatibility workarounds. They worked, but nobody could hold the entire design in their head at once. And if nobody can hold it in their head, nobody can truly audit it.
Donenfeld decided to build his own VPN protocol from scratch. But this was not the kind of decision a normal developer makes on a Tuesday afternoon. Donenfeld was not a normal developer. He had been doing kernel development since his teens. His online handle, zx2c4, came from a keyboard pattern, and his personal website was a showcase of projects ranging from password managers to cryptographic tools. He understood both the kernel and modern cryptography well enough to attempt something that most engineers would consider reckless: a VPN implemented directly in the Linux kernel, using only the most modern, most battle-tested cryptographic primitives, with no configuration options, no cipher negotiation, and no backward compatibility.
The design philosophy behind WireGuard was subtraction. Where OpenVPN gave users dozens of cipher suites to choose from, WireGuard offered exactly one combination. Curve twenty-five thousand five hundred nineteen for key exchange. ChaCha twenty and Poly thirteen oh five for encryption and authentication. BLAKE two s for hashing. These were not exotic choices. They were the cryptographic primitives that the security community had converged on as the strongest, fastest, and most well-understood options available. By removing choice, Donenfeld removed an entire category of vulnerability: misconfiguration.
Here is a number that tells the whole story. The original WireGuard kernel implementation was roughly four thousand lines of code. Four thousand. A single senior security researcher could read every line in an afternoon. Compare that to OpenVPN's seventy thousand, or the sprawling mess of IPSec implementations that could run to six hundred thousand lines across all the supporting libraries. This was not minimalism for its own sake. This was an engineering bet that a smaller attack surface is a safer attack surface.
The interface design was equally stripped down. Setting up a WireGuard connection looked almost identical to setting up a normal network interface. You created a virtual interface, assigned it an IP address, and told it the public keys of the peers you wanted to connect to. That was essentially it. No certificate authorities, no complex handshake negotiations, no XML configuration files. If you had ever set up an SSH key pair, you already understood the mental model.
Donenfeld called the core concept "cryptokey routing." Every peer is identified by its public key. Every packet is associated with a peer through that key. The routing table maps public keys to allowed IP ranges. When a packet arrives, WireGuard checks the source, looks up the key, and either decrypts and forwards it or silently drops it. If the packet does not come from a known peer, WireGuard does not respond at all. The interface is completely silent to unauthorized traffic, which from a security perspective is exactly what you want. If an attacker cannot tell whether a WireGuard endpoint is even there, they cannot begin to attack it.
The WireGuard logo is a snake, and the story behind it is the kind of detail that turns a technology story into a human one. While visiting a museum in Delphi, Greece, Donenfeld saw a stone engraving of the mythological Python, the great serpent that guarded the Oracle. Something about the image stuck with him, and when WireGuard needed a visual identity, he went back to that engraving. The snake curling around itself, ancient and patient, became the face of a protocol designed to be equally timeless and minimal.
It is a fitting symbol. The Python at Delphi was the guardian of hidden knowledge, and WireGuard guards data by making the tunnel itself nearly invisible. When WireGuard is running on a server, port scans reveal nothing. The protocol does not respond to unauthenticated packets. There is no handshake banner, no version string, no hint that anything is listening at all. The snake does not announce itself.
Getting code into the Linux kernel is one of the hardest things a developer can do. The kernel maintainers are famously exacting, and the review process can drag on for years. Donenfeld submitted WireGuard patches and then did something unusual: he backported the code to every Linux kernel version going back to three point ten. This meant that system administrators did not have to wait for the latest kernel to try WireGuard. They could install it on their existing infrastructure, test it, and report bugs. By the time the kernel merge discussion became serious, WireGuard already had a massive base of users who had tested it in production.
In twenty eighteen, Linus Torvalds, the creator of Linux, posted a message that went viral in the security community.
Can I just once again state my love for it and hope it gets merged soon? Maybe the code is not perfect, but compared to the horrors that are OpenVPN and IPSec, it is a work of art.
Linus Torvalds calling someone else's code "a work of art" is roughly equivalent to a Michelin-starred chef complimenting your home cooking. It does not happen. The Linux kernel community is not known for its warmth toward outside contributions, and Torvalds himself is legendary for his blunt criticism. For him to use the phrase "work of art" about a VPN protocol was remarkable.
There was one major obstacle. Donenfeld had written his own cryptographic library called Zinc, because he felt the existing Linux kernel crypto API was too cumbersome and inefficient. Torvalds publicly agreed, writing that the kernel crypto model was "hard to use, inefficient, and completely pointless when you know what your cipher is." But not everyone shared that view. Some kernel maintainers insisted that WireGuard should use the existing crypto API, even if it was clunky.
In the end, Donenfeld compromised. He ported WireGuard to the existing crypto infrastructure and worked on getting Zinc elements imported into the kernel gradually. In March twenty twenty, WireGuard was merged into Linux kernel five point six. The protocol that started as a stealth channel for a rootkit was now part of the operating system that runs most of the internet.
Right now, your infrastructure has a gap. Your pinkserver sits on your home network in Kall. Your VPS runs on Scaleway in a data centre somewhere in Europe. Your MacBook travels with you. Your phone is wherever you are. These machines need to talk to each other, and right now, each connection is a separate problem to solve. SSH tunnels here, exposed ports there, relying on your RUTM fifty-one's public IP and hoping the cellular carrier does not change things without telling you.
WireGuard solves this by turning all your devices into peers on a single virtual private network. Install it on the VPS, the pinkserver, the MacBook, the phone. Exchange public keys. Define which IP ranges each peer is allowed to use. Done. From that point on, every device can reach every other device as if they were on the same local network, regardless of where they physically are. The traffic is encrypted end to end with the strongest available cryptography, and the overhead is almost nothing. WireGuard adds roughly four percent to your data usage, compared to twenty percent for OpenVPN.
There is a company called Tailscale that built an entire business on top of WireGuard. They added automatic key exchange, a coordination server, and a user-friendly interface, but underneath it is pure WireGuard. If you want the simplicity of Tailscale with the control of running everything yourself, you can set up raw WireGuard in about fifteen minutes. The configuration file for each peer is about ten lines long. Compare that to the novel-length OpenVPN configuration files that network administrators have nightmares about.
For your specific setup, WireGuard means your Pärkit database on pinkserver becomes reachable from your VPS without exposing PostgreSQL to the public internet. Your BMW telemetry data can flow from your router through an encrypted tunnel to your dashboard. Your development workflow gets simpler: rsync to the VPS through the tunnel, no SSH key juggling, no port forwarding. Everything just works, because on the WireGuard network, every device is a neighbour.
There is a deeper lesson in the WireGuard story that goes beyond networking. Jason Donenfeld proved something that the software industry keeps forgetting: that security comes from simplicity, not from features. Every line of code is a potential vulnerability. Every configuration option is a potential misconfiguration. The safest system is the one small enough for a single person to hold in their head.
This is not a lesson that the industry learns easily. The trend in software is always toward more: more options, more compatibility, more abstraction layers. WireGuard went the other direction and won. It is faster, more secure, and easier to use than systems that took decades and hundreds of developers to build. Four thousand lines, written mostly by one person, reviewed and loved by the creator of Linux himself.
The snake from Delphi guards the tunnel, and the tunnel is waiting. In the next episode, we will meet the person responsible for the software that keeps that tunnel alive after your server boots, the most controversial figure in the Linux world, a man who received death threats for changing how services start. His name is Lennart Poettering, and the software he built is called systemd, and you are already completely dependent on it whether you know it or not.