WireGuard

## What a WireGuard peer is **WireGuard** is a layer-3 VPN tunnel that carries IP packets inside UDP. It has no RFC. Its specification is a paper by its author (the *WireGuard whitepaper*), so every rule below is the paper's. In WireGuard a **peer** is the other end of a tunnel, and it is identified **strictly by its public key**: a 32-byte **Curve25519** point. Every interface holds one private key and a list of peers. Each peer entry is that peer's public key, the addresses it may use (its **allowed IPs**) and, optionally, the outer IP address and UDP port where it can be reached. So none of these identifies a peer: - **not an IP address**: the outer address is learned and may change as the peer roams, and the inner addresses are a filter attached to the key; - **not a username or password**: the protocol has no user concept at all; - **not a certificate**: there is no X.509 parsing, no certificate authority and no chain validation inside WireGuard. ## Where the keys come from The paper takes its key-distribution model from SSH. Two peers exchange static public keys by **some unspecified, out-of-band mechanism**: a ticket, a signed email or a provisioning system. After that they can talk. A public key is short (44 characters in Base64), so it is easy to paste. WireGuard deliberately treats key distribution as the wrong layer to solve. Whatever system you use to hand out and withdraw keys sits outside the protocol. One rule follows from the identity model. **Every device gets its own key pair.** The paper warns that two distinct peers should not share private keys, and a shared key would make two machines indistinguishable to everyone else. ## One fixed cryptographic suite The whole protocol uses one set of primitives, named in the handshake's construction string `Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s`: | Job | Primitive (per the paper) | |---|---| | Handshake pattern | Noise `IK`, with the optional pre-shared key mixed in by the `psk2` modifier | | Key agreement | Curve25519 Diffie-Hellman | | Key derivation | HKDF built on BLAKE2s | | Packet encryption and integrity | ChaCha20-Poly1305 authenticated encryption | | Hashing and MACs | BLAKE2s | | Cookie encryption under load | XChaCha20-Poly1305 | No field in any WireGuard message lists algorithms, and no configuration knob selects one. Two correctly configured peers always use the same suite, because there is only one. ## Why no negotiation is a feature The paper calls WireGuard **cryptographically opinionated**: it *intentionally lacks cipher and protocol agility*. The reasons: - **No downgrade surface.** A protocol that negotiates can be pushed toward the weakest option both sides still accept. With nothing offered, there is nothing to strip. - **No proposal mismatch.** A negotiating protocol such as IKEv2 has to agree a proposal before anything works, and a mismatch between two ends is a common deployment failure. WireGuard cannot have that failure. - **A smaller protocol.** The paper argues that cipher agility *increases complexity monumentally*, and it puts its own implementation at under 4,000 lines of code. - **A one-round-trip handshake.** With no algorithms to agree, the first message can already carry the initiator's encrypted identity. ## What it costs Fixed cryptography is a trade, and an operator should be able to say what was given up: 1. **No fallback.** If a hole is found in one of the primitives, the paper says *all endpoints will be required to update*. You cannot switch a running fleet to another cipher by configuration. 2. **No algorithm policy.** A deployment that must use a specific approved algorithm set cannot ask WireGuard for it. 3. **Keys are your system.** Because identity is a bare public key, issuing, recording and withdrawing keys is the operator's job. ## A common misreading "Fixed" describes the **algorithms**, not the **keys**. Each handshake creates fresh ephemeral keys, and the paper has a new session created roughly every `Rekey-After-Time` (120 seconds). The static identity keys stay the same until the operator replaces them. The session keys keep changing, and that is where WireGuard's forward secrecy comes from.