But why that VPN? How WireGuard made it into Linux

Even the best of ideas can take their own sweet time making it into the kernel

Maybe someday – maybe – Zero Trust will solve many of our network security problems. But for now, if you want to make sure you don't have an eavesdropper on your network, you need a Virtual Private Network (VPN).

There's only one little problem with commercial VPNs: many of them are untrustworthy. So, what can you do? Well, run your own of course is the open-source answer. And, today, your VPN of choice is Linux's built-in VPN: WireGuard.

Why WireGuard rather than OpenVPN or IKEv2? Because it's simpler to implement while maintaining security and delivering faster speeds. And, when it comes to VPNs, it's all about balancing speed and security.

So, if WireGuard is all that, why did it take so long to make it into the Linux kernel? After all, its creator, Jason Donenfeld, first came up with the ideas behind WireGuard in 2015.

Because even when you have a great idea and implement it well, it doesn't mean that things move quickly in Linux development circles. No, not even when Linus Torvalds himself declared "Can I just once again state my love for it."

Torvalds loved WireGuard because, "Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art."

A work of art? Seriously? Yes, seriously.

Donenfeld developed WireGuard as a replacement for older secure tunneling protocols such as IPSec and OpenVPN. Donenfeld, never one to shy away from saying what he thought, has described these older protocols as "overwhelmingly difficult."

Just in terms of sheer lines of code, for example, OpenVPN weighs in at 70,000 lines of code. Or, if implemented with OpenSSL, as it usually is, it comes in at a hefty 600,000 total lines of code. WireGuard? It's a mere 4,000 lines of code. That makes it, as many security experts have pointed out, much simpler to audit for security problems.

One reason why WireGuard is so much simpler, but also why it took so long to make it into Linux, is that Donenfeld disliked Linux's built-in cryptographic subsystem. He thought its application programming interface (API) was too complex and difficult.

He suggested it be supplemented with a new cryptographic subsystem: His own Zinc library. That didn't go over so well, as you might imagine, with developers who'd spent years on Linux's existing cryptographic systems. Besides that aspect, many thought Donenfeld was wasting time reinventing the cryptographic wheel.

Donenfeld was willing to work with the community. As he wrote on the Linux Kernel Mailing List (LKML), "There's no reluctance to work with the community. I'm pretty deeply committed to this, as evidenced by the multitudes of patch submissions, discussions, and popping around from conference to conference discussing with folks face to face."

That didn't slow down the controversy, but Donenfeld had an important ally, who came to his aid once again: Torvalds.

Torvalds wrote, "I'm 1000% with Jason on this. The crypto/ model is hard to use, inefficient, and completely pointless when you know what your cipher or hash algorithm is, and your CPU just does it well directly."

In the end, Donenfeld compromised. "WireGuard will be ported to the existing crypto API. So it's probably better that we just fully embrace it, and afterward work evolutionarily to get Zinc into Linux piecemeal."

That's exactly what happened. Some Zine elements have been imported into the legacy crypto code in the Linux 5.5 kernel. That laid the foundation for WireGuard to finally ship in Linux.

So it was that Wireguard was merged into the Linux 5.6 kernel in March 2020. It's also available as a backport to the stable Linux 5.4 kernel. In short, if you want to run your own WireGuard server today on a modern Linux distribution you're ready to go.

Today, WireGuard is a layer 3 secure VPN. While it started in Linux, WireGuard code quickly became cross-platform. Today it runs on Windows, macOS, BSD, iOS, and Android. Indeed, there's already a native, albeit experimental Windows WireGuard port. You name it, you can probably run WireGuard on it.

Behind the scenes, WireGuard uses Curve25519 for key exchange, BLAKE2s for hashing, and ChaCha20 and Poly1305 for authentication. It also includes other state-of-the-art cryptographic tools such as the Noise protocol framework, Curve25519, SipHash24, and HKD. In other words, breaking WireGuard isn't easy.

It is, however, easy to deploy and use. Because WireGuard presents a virtual interface – wg0 – you can configure it with standard Linux networking utilities such as firewalld and ifconfig(8).

WireGuard does all this by securely encapsulating IP packets over UDP. Its authentication and interface design have more to do with Secure Shell (SSH) than other VPNs' more complex setups. You simply configure the WireGuard interface with your private key and your peers' public keys, and you're ready to network in private.

Mind you, WireGuard isn't perfect. Sure, France's The Center for Direct Scientific Communication (CCSD) has shown cryptographic proof for its "correctness, message secrecy, forward secrecy, mutual authentication, session uniqueness, and resistance against key compromise impersonation, identity mis-binding, and replay attacks."

However, there's more to network security than just locking down the transmitted data. By itself, for example, WireGuard doesn't dynamically assign IP addresses. So, by itself, every time you use it, you get the same, easy-to-track static IP address. That, in turn, means WireGuard must log and store your IP address and timestamps. Both OpenVPN and IKEv2 avoid these security concerns by dynamically assigning IP addresses.

You can work around this. Indeed, three commercial VPNs, CyberGhost, IVPN, and early WireGuard champion, Mullvad, already provide such workarounds. And, of course, if you're running it on your own server and using it to safely network in your working from home users, you aren't going to care much about these issues.

As for me, WireGuard is what I use today and, I expect, eventually, it will be what you use tomorrow. ®

Source