WireGuard merged into Linus's tree during the 5.6 merge window in late January 2020, having sat in Dave Miller's networking tree since December 2019, and shipped in the 5.6 release this month (kernel.org, The Register).
The number everybody quotes is about 4,000 lines, against something north of 100,000 for OpenVPN. The project's own stated goal is that it be "comprehensively reviewable by single individuals".
That's a design goal, not an audit result, and the distinction matters rather a lot.
Why small is the argument¶
Most security engineering tries to make a large attack surface safe. WireGuard goes the other way and makes the surface small enough that a competent person can hold all of it in their head at once. You can inspect a shed; you cannot inspect a cathedral.
The mechanisms:
- No cryptographic agility. One cipher suite: ChaCha20, Poly1305, Curve25519, BLAKE2s, HKDF. No negotiation, so no downgrade attack, and no negotiation code to get wrong. Upgrading means a new protocol version rather than a new option.
- No key management in the data plane. Peers are public keys, configured out of band. There's no PKI, no certificate parsing, and therefore no X.509 parser, historically one of the richest sources of remote vulnerabilities in TLS implementations.
- Silence by default. An unauthenticated packet gets no response whatsoever, which removes a whole class of scanning and amplification behaviour.
- Stateless until authenticated. The handshake is built so the responder allocates nothing that an unauthenticated peer can make it allocate.
Every one of those is a decision to not support something. The line count is the consequence, not the goal.
What has and has not been verified¶
This gets overstated, so be careful with it.
In May 2019, researchers at INRIA published a machine-checked proof of the WireGuard protocol using CryptoVerif. That verifies the protocol design. It isn't a verification of the kernel implementation, and those are two different claims. A proven protocol with a buggy implementation is still a buggy system.
The open question is the in-kernel code: a formal third-party audit of the merged implementation would settle it, and we have not found one published. The claim "formally verified" gets applied to WireGuard a good deal more loosely than the record supports, and the thing that would fix that is an audit of the C, not another proof of the handshake.
The counter-example it provides¶
The default direction of travel for a successful protocol is to accumulate options, because every option has an advocate with a real use case behind them. TLS, SSH and IPsec all went that way and all paid for it in implementation complexity and downgrade attacks.
WireGuard is the demonstration that the other path is open, and that the cost of taking it, which is telling people no, gets paid in product management rather than in engineering.
What this makes possible¶
A VPN that is four thousand lines and configured with a public key per peer is a different kind of component from one that needs a PKI and a support contract.
A small business gets a real private network without a consultant. A peer is three lines of config and a key pair. Two sites, a handful of laptops and a cloud box become one network in an afternoon, with no certificate authority to stand up, no CRL to publish and nothing to renew at two in the morning. That used to be a project; it is now a config file you can read out loud.
Encryption becomes the default for links nobody bothered to encrypt. Database replication between two racks, a monitoring feed, a backup stream to a colocation box: all of those have historically gone in the clear across a private line because IPsec was too much trouble for the benefit. At a handshake this cheap and a kernel data path this fast, there is no longer an excuse, and one entire category of "we assumed the link was trusted" incident goes away.
Roaming stops being special. The protocol identifies peers by key rather than by address, so a laptop moving from office Wi-Fi to a phone tether to a hotel network keeps the same tunnel. For someone working from a country with unreliable connectivity, or over a link that drops every few minutes, this is the difference between a usable connection and a support ticket.
And for engineering itself: a boundary you can read in an afternoon is a boundary you can reason about. The whole class of bug that comes from negotiation, option matrices and protocol downgrade simply has nowhere to live here.
The code can be readable while the endpoint still belongs to somebody else.
The same simplicity that makes WireGuard easy to self-host makes it easy to build a consumer VPN business on, and that industry is already large, already advertising heavily and already selling privacy as a subscription. The pitch is that your ISP should not see your traffic. The mechanism is that a company you have never met sees it instead.
Be precise about what the protocol does and does not protect. WireGuard protects the link. It does not protect you from the operator of the far end, who terminates your tunnel, sees every destination you connect to and is subject to whichever jurisdiction's legal process applies to them. Swapping your ISP for a VPN provider is a change of who holds the log, not a removal of the log.
There is a specific technical wrinkle that makes the commercial version worse than it looks. WireGuard's interface is stateless and keeps no per-peer session concept, so a server assigns each peer a fixed tunnel address and keeps that mapping in its config. The provider therefore holds a durable identifier for you by construction. A "no logs" claim sits on top of a protocol whose server side needs a persistent key-to-address table to function at all. We are not accusing any provider. The architecture does not help them keep the promise.
The code is published and small; ownership sits with whoever operates the endpoint you dial. That is the good news, because unlike a registry or a certificate authority, this chokepoint is one you can simply take back: a thirty-pound box in a cupboard at home, a key pair and a port forward. Run your own endpoint and the question of who to trust with your traffic stops being a procurement decision.
Two things to keep an eye on as this spreads. First, whether the protocol stays small once large vendors want features in it. The pressure to add negotiation will arrive the moment somebody important needs an exception. Second, whether the self-hosted path stays as easy as the subscription path. Today the self-hosted version is simpler than the commercial one, which is a rare and valuable position to be in, and it is worth defending.