● Maronix keeps you moving freely. Learn why
← Protocols
Protocols & Privacy Technology Reference Intermediate

What Is WireGuard?

WireGuard is a layer-3 tunnel over UDP with a deliberately tiny codebase and a fixed set of cryptographic primitives. Small, fast, auditable, and not built for censorship.

Wireguard logo: red background with a white coiled dragon

Definition#

WireGuard is a layer-3 network tunnel that runs over UDP, using a fixed set of modern cryptographic primitives and a handshake taken from the Noise Protocol Framework. It is deliberately small: by the authors’ own comparison in their talks, around four thousand lines of code, against roughly a hundred thousand for OpenVPN and several hundred thousand for IPsec.

What problem it solves#

Two problems at once, and they are related.

Complexity. Long-lived protocols accumulate options: version negotiation, cipher suites, plugin systems, compatibility shims. Every option is a place where implementations disagree and bugs live. WireGuard’s response is to remove the options. Its protocol name is a contract: Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s names every primitive in use, and there is nothing else to negotiate.

Auditability is the reason a small protocol matters: one can be read. The cryptography has been examined formally and by peer-reviewed analysis: Dowling and Paterson’s A Cryptographic Analysis of the WireGuard Protocol proved key indistinguishability and authentication properties for the key exchange, under standard assumptions, and documented the reasoning around key-compromise impersonation attacks.

How it works, at the depth that matters#

Primitives. From the project’s own protocol description: Curve25519 for the Diffie-Hellman operations, ChaCha20 authenticated with Poly1305 following RFC 7539 for the symmetric layer, BLAKE2s for hashing and keyed hashing, SipHash24 for hash table keys, and HKDF for key derivation.

The handshake uses the Noise IK pattern, which authenticates both parties in one round trip while hiding their identities from a passive observer, and rekeys regularly to maintain perfect forward secrecy. The project describes the handshake as occurring every few minutes specifically so that keys rotate.

Transport is UDP for every packet. There is no TCP mode and no fallback.

Denial of service is addressed directly. Because any UDP endpoint can be made to do work, WireGuard adds a cookie mechanism: a returning client proves it has seen a recent handshake before the server does expensive work. The formal-verification paper describes this cookie MAC system as one of the four mechanisms the protocol is built from, alongside the key exchange and the timer state machine.

An optional pre-shared key can be mixed into the public-key cryptography. The project documents this as being useful if an additional layer of symmetric protection is wanted.

Timestamps are embedded too. WireGuard puts TAI64N timestamps in its data packets, which is what lets it discard stale packets cheaply and recognise replay.

What it explicitly does not do#

  • No cipher agility. You cannot add a cipher. The protocol’s fixed primitive set is a deliberate security decision and a deliberate limitation.
  • No TCP fallback. If UDP is blocked or heavily throttled, WireGuard has no answer. This is the single most common practical failure.
  • No built-in obfuscation. Nothing in the protocol tries to hide that it is a tunnel.
  • No dynamic users. Membership is a configuration file. There is no protocol-level mechanism for adding or removing a peer at runtime.
  • No resistance to blocking. WireGuard was not designed against censorship, and there is no claim that it was.

How a censor sees it#

Poorly disguised, and honestly so.

A WireGuard connection is a UDP flow to a single address and port that begins with a recognisable handshake and then carries steady traffic. UDP is also a large share of ordinary internet traffic, so it is not unusual on its own. A fixed peer address with sustained bidirectional UDP is still a usable signature, and WireGuard provides no mechanism to vary it.

There is a second, subtler exposure that is not WireGuard’s fault and is worth understanding anyway: a WireGuard tunnel has a characteristic packet size distribution, because it encapsulates inner IP packets and adds its own framing. That is the same class of weakness documented for OpenVPN.

When it fits#

Good fit: you want the simplest thing that is well audited and fast; you are on a network that does not block UDP; you control your own server or trust your provider to run it properly; you value a small code surface.

Poor fit: UDP is blocked or throttled where you are; you need to appear as ordinary web traffic; you need credentials that change without touching configuration.

Sources

  1. WireGuard: Protocol and Cryptography WireGuard
  2. WireGuard: Next Generation Kernel Network Tunnel (whitepaper) WireGuard
  3. A Cryptographic Analysis of the WireGuard Protocol (ePrint 2018/080) IACR
  4. The Noise Protocol Framework Trevor Perrin
  5. RFC 7539: ChaCha20 and Poly1305 for IETF Protocols IETF

Last reviewed October 30, 2026. This article was revised after publication. Corrections and additions are welcome.