The Noise-based handshake, the fixed set of primitives, why the codebase is small, and where to report a vulnerability.
Most VPN protocols let the two ends negotiate which cryptography to use. That flexibility is where a great deal of historical breakage lives: a downgrade path, an obsolete cipher nobody removed, a configuration that looked fine and wasn’t.
WireGuard doesn’t negotiate. The primitives are chosen, fixed, and part of the protocol. If they need to change, the protocol version changes and both ends update — a deliberate trade of flexibility for the absence of a whole class of misconfiguration.
The primitives
Section titled “The primitives”| Job | Primitive |
|---|---|
| Handshake framework | Noise |
| Key agreement | Curve25519 |
| Authenticated encryption | ChaCha20 with Poly1305 |
| Hashing | BLAKE2 |
| Hash table keys | SipHash24 |
| Key derivation | HKDF |
The handshake is built on the Noise protocol framework rather than invented for the occasion, which means its properties have been analysed independently of WireGuard. It gives the tunnel forward secrecy: keys rotate, so recovering a peer’s long-term private key later does not decrypt traffic captured earlier.
ChaCha20-Poly1305 is worth a note. It has no widespread dedicated hardware acceleration in the way AES does, which sounds like a disadvantage until you measure it — on general-purpose CPUs with vector instructions it lands in the same territory as AES-NI, and it is fast on hardware that has no crypto acceleration at all. That matters for the phones and routers WireGuard is meant to run on.
A codebase you can actually audit
Section titled “A codebase you can actually audit”WireGuard’s implementation is small on purpose, and this is a security argument rather than an aesthetic one.
Auditing is bounded by human attention. A reviewer given a large codebase is not really reviewing it; they are sampling it and hoping the sample was representative. The IPsec implementations and the OpenVPN-plus-OpenSSL stack are both large enough that thorough review is a project rather than a task, even for a well-resourced team. WireGuard aims to be comprehensively reviewable by one competent person.
Living inside the Linux kernel cuts the surface further: there is no separate daemon holding state, and no userspace-to-kernel plumbing to get wrong.
Formal verification
Section titled “Formal verification”The protocol has been subjected to formal verification — machine-checked proof work rather than argument by inspection. The official site keeps a page on it and links the papers. This is unusually strong evidence for a protocol in production use, and it is one of the more compelling reasons to trust the design.
The whitepaper
Section titled “The whitepaper”The protocol is defined in a technical whitepaper, an academic paper that sets out the design, the cryptographic reasoning, and the decisions behind it. It is the authoritative description, and it is readable — if you want to know why something works the way it does rather than just how, read it.
Read the technical whitepaper (PDF)
Reporting a vulnerability
Section titled “Reporting a vulnerability”This is the part the original site buries, so it goes here in plain sight.
Security issues go to security@wireguard.com, and only there. Not the mailing list, not the IRC channel, not the general contact address. Sending a vulnerability to a public mailing list discloses it to everyone at once, including people who will use it.
The reverse holds too: that address is for security issues only. A configuration problem or a question about routing should go to the project’s usual channels, where people who can help are actually reading.
Honest about the edges
Section titled “Honest about the edges”Cryptographic design is a set of trade-offs, and WireGuard publishes its own list of them rather than leaving you to discover them. Read Known limitations — it covers post-quantum secrecy, identity hiding, denial of service, and the assumptions the protocol makes about your system clock.