WireGuard is a new type of VPN which aims to be simpler to set up and maintain than current VPNs and to offer a higher degree of security. The software is free and open source—it's licensed GPLv2, the same license as the Linux kernel—which is always a big plus in my book. It's also designed to be easily portable between operating systems. All of that might lead you to ask: in a world that already has IPSEC, PPTP, L2TP, OpenVPN, and a bewildering array of proprietary SSL VPNs, do we need yet another type of VPN?
OK, but why?
I've seen a few new VPN designs pop up in the last few years—ZeroTier and Tinc come to mind—and each time, I've thought, "I should really look into that." And then I haven't. I use OpenVPN heavily; I'm thoroughly familiar with it, and it scratches most of my VPN-related itches pretty well.
So how did WireGuard rattle my cage hard enough to get me to actually play with it? It had something you almost never see: a positive comment about its code from none other than Linus Torvalds.
Can I just once again state my love for [WireGuard] and hope it gets merged soon? 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.Linus Torvalds, on the Linux Kernel Mailing List
That was enough to get me to sit up and pay attention. If you think "maybe it isn't perfect, but" is damning with faint praise, you clearly aren't familiar with Torvalds' acerbic writing style.
Fewer lines of code
A little more research gave me some insight into why Torvalds might have been so uncharacteristically positive. WireGuard weighs in at around 4,000 lines of code; this compares to 600,000 total lines of code for OpenVPN + OpenSSL or 400,000 total lines of code for XFRM+StrongSwan for an IPSEC VPN. Two orders of magnitude fewer lines of code mean a lot less attack surface to find flaws in.
A much smaller codebase also means code that's more likely to work the way it's supposed to. One of my biggest operational beefs with OpenVPN is how its tunnels can either crash or hang.
This probably won't happen frequently enough for you to notice if you only have a few tens of clients, and most of those are manually operated by a human clicking something to connect and disconnect their tunnel as needed anyway. But if you want to manage a network with hundreds of clients, all of which should automatically manage their own always-on tunnels, it's a big problem.
OpenVPN features ping and ping-restart configuration arguments that should take care of this for you, but they don't. I've spent more of my time crafting and maintaining watchdog scripts that carefully check for, kill -9, and restart OpenVPN daemons than I like to think about. I'd love to be able to replace them with something that just works.
Simpler setup
I don't want to sugarcoat this: VPNs aren't simple, and WireGuard doesn't suddenly make them a kindergarten project. With that said, it took me a few days of careful, determined, and dedicated reading, implementation, and testing before I understood OpenVPN well enough to really have any idea what I was doing. A few years later, I needed another week or two of trawling the Internet for how-tos and piecing them together in order to build a large-scale OpenVPN-based network. I spent another half-day or so reading about the latest advancements in configuration and best practices before updating my configurations for last year's Ars Technica OpenVPN guide.
By rather sharp contrast, I created working, stable, documented configurations for a scalable, secure WireGuard network in about six hours on a Sunday afternoon. Much of this greater simplicity in setup and configuration is due to WireGuard's deliberate, principled rejection of cryptographic agility.
Stronger algorithms
WireGuard deliberately eschews "industry standard" algorithms which have long-standing weaknesses in favor of only the latest, toughest primitives. From the WireGuard website:
- ChaCha20 for symmetric encryption, authenticated with Poly1305, using RFC7539's AEAD construction
- Curve25519 for ECDH
- BLAKE2s for hashing and keyed hashing, described in RFC7693
- SipHash24 for hashtable keys
- HKDF for key derivation, as described in RFC5869
This all looks impressive enough, but I'm no cryptographer. I was still a little concerned about WireGuard's future security, because there's nothing configurable about it, and its keys were considerably smaller than what I was used to. Luckily for me, publishing my first three WireGuard VPN configs on my own blog was enough to catch the attention of Jason Donenfeld, WireGuard's author and principal developer. That gave me the chance for a little desperately-needed Q & A. (Please consider any errors in the following content mine, not Jason's. Did I mention I'm not a cryptographer?)
As someone who doesn't really understand cryptography but who has been using it actively for 20 years, the combination of a short key and no configuration options made me a bit nervous. With OpenVPN, I like to err on the side of caution by using a honking big key. Why can't I do the same with WireGuard? Why am I limited to a 256-bit key with WireGuard, while OpenVPN offers me a whopping 4,096 bits? It turns out that a 4,096 bit key is kind of ridiculous.
If you have to brute-force a 256-bit key, you have 2256 total combinations to work through. If you assume that on average, you'll uncover the solution halfway through the problem set; that still leaves you with 2255 failures before success. Now assume that you have an extremely powerful system, capable of trying 38,000,000 keys per second, and local access to the public side of the keypair. If you're relying on brute force, it'll take you a little more than 1.52 × 1069 seconds on average to come up with the winning key. Given that the estimated age of the universe itself is 4.32 × 1017 seconds, that's probably sufficient.
The reason OpenVPN (and almost all VPN solutions) use such ridiculously long keys is that you don't have to brute-force them. An actual cryptographic attack on the algorithms commonly used for VPNs (or for HTTPS connections to websites) looks a lot more like a dictionary attack than a brute-force attack; you can discount great swathes of the problem space without having to actually try them.
The tremendous key length—and in some cases, repeated executions of the same algorithm (anybody else remember DES vs 3DES?)—is basically a naive "well, do it harder then!" mitigation that attempts to confound cryptographic attacks or expand the problem set to something so ludicrously huge that, even if you can just throw away all but 0.000000001% of it, it's still too much to bash through.
As long as the algorithms underlying WireGuard remain unbreached, a 256-bit key isn't just "strong enough until computers get faster." It's strong enough that simple physics prevent a brute-force approach—at least, until quantum computing comes into play. Quantum computers are odd beasts that have very different use cases than conventional computers, but one of the things they are extremely good at is attacking asymmetric (public/private key) cryptography. We're not capable of creating a quantum computer large enough to attack a 256 bit key yet, but it's expected to happen eventually. If you're sufficiently paranoid that you want future proofing against QC, you can optionally add a PSK (Pre-Shared Key) layer to WireGuard's encryption.
[contf] [contfnew] 
Ars Technica
[contfnewc] [contfnewc]
