What is WireGuard?

WireGuard is a VPN protocol written by Jason A. Donenfeld and merged into the Linux kernel in version 5.6, released in March 2020. It is defined by what it leaves out: no cipher negotiation, no certificates, no TCP mode, no configuration options that change its security properties.

The cryptography, which is not configurable

Purpose	Primitive
Key exchange	Curve25519
Symmetric encryption	ChaCha20
Authentication	Poly1305
Hashing	BLAKE2s
Key derivation	HKDF
Cookie hashing	SipHash24

There is no way to select a different set. If one of these is ever broken, the answer is a new protocol version rather than a configuration change.

That sounds fragile and is a deliberate response to history: cipher negotiation is where a long list of real TLS vulnerabilities lived, because an attacker who can influence what gets negotiated can often force both ends down to something weaker. Removing the negotiation removes the class.

Cryptokey routing

The concept that makes WireGuard's configuration so short. Each peer is identified by a public key, and each key is associated with a list of addresses it is allowed to use, called AllowedIPs.

That single field does two jobs:

• Outbound, it is a routing table: send these destinations to this peer.
• Inbound, it is an access control list: a packet arriving from this peer claiming a source address outside its list is dropped.

Two directions, one field, no separate firewall configuration for the common case.

The handshake

WireGuard uses the Noise protocol framework, specifically the Noise_IKpsk2 pattern. The exchange is two messages: an initiation and a response. After those two, both ends have session keys.

Three properties fall out of it:

• 1-RTT. One round trip and the tunnel carries data.
• Identity hiding. The initiator's public key is encrypted, so a passive observer cannot read who is connecting.
• Optional preshared key. The psk2 in the pattern name. A symmetric key mixed into the handshake alongside the Diffie-Hellman result, which provides a hedge against a future attacker with a quantum computer breaking Curve25519.

The handshake also carries a TAI64N timestamp, and a peer rejects any initiation whose timestamp is not greater than the last one accepted from that key. That is the replay defence, and it is why a device with a badly wrong clock cannot maintain a tunnel.

Statelessness, and why roaming just works

There is no session in the TCP sense. Each packet is independently authenticated, and when a packet arrives from a new source address, the server updates its record of where that peer is.

Practically: walk out of Wi-Fi onto mobile data and nothing reconnects, because nothing disconnected. The tunnel simply continues from the new address. This is the difference people feel daily.

Silence by default

A WireGuard endpoint does not respond to anything it cannot authenticate. Send it a random packet, or a handshake signed by a key it does not know, and it answers with nothing at all.

The consequence is that a port scan cannot distinguish a WireGuard server from a closed port. That is a deliberate property, not an accident, and it is why diagnosing a failed handshake gives you so little to work with.

What it does not do

• No TCP. UDP only, with no fallback. A network that blocks UDP blocks WireGuard completely, and no configuration changes that.
• No obfuscation. The handshake has a recognisable structure. Providers that get through restrictive networks wrap WireGuard in a separate layer.
• No dynamic address assignment. Each peer gets a fixed tunnel address, which the server must remember to route to it.

That last point is the privacy caveat the project documents in its known limitations: a naive deployment holds a longer-lived association between a user and an address than a typical OpenVPN setup does. It is solvable with rotating keys and in-memory state, but it is the operator's problem to solve rather than something the protocol handles.

Why it is fast

Three compounding reasons. It runs in the Linux kernel, so packets are not copied to userspace and back. ChaCha20-Poly1305 is fast in software, which matters on phones, tablets and routers without AES hardware acceleration. And the per-packet overhead is small.

Measure it yourself with the speed test rather than trusting a benchmark from someone else's hardware.

Where you will meet it

Every major consumer VPN now offers it, several corporate products are built on it, and it is the default on Linux where the kernel already has the code. The Linux setup guide covers wg-quick, which is the shell script that turns a config file into a working interface and is most people's first contact with it.