The WireGuard protocol is a variant of the
Noise Protocol Framework IK handshake pattern, as illustrated by the choice of Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s for the value of the
Construction string listed on p10 of the Whitepaper. The
key exchange, or handshake, combines long-term and ephemeral Diffie-Hellman values using
Curve25519. Each pair generates a set of public and private key pairs using Curve 25519, the public keys are exchanged, with each pair then assigned an IP address (generally
RFC 1918) to utilize with the WireGuard tunnel. Once the keys have been confirmed by both peers, the Noise Protocol is used to generate a shared
ChaCha20 session key for
symmetric encryption authenticated with
Poly1305.
Key derivation functions are handled using
HKDF and
Base64-encoded private keys, public keys and preshared keys. From that model, CryptoVerif’s automated game hops show, across unlimited parallel sessions, that the protocol guarantees mutual authentication,
IND-CCA session-key secrecy,
forward secrecy and post-compromise security even if long-term keys later leak and state is wiped.
Optional pre-shared symmetric key mode WireGuard supports
pre-shared symmetric key mode, which provides an additional layer of
symmetric encryption to mitigate future advances in quantum computing. This addresses the risk that traffic may be stored until quantum computers are capable of breaking
Curve25519, at which point traffic could be decrypted. Pre-shared keys are "usually troublesome from a key management perspective and might be more likely stolen", but in the shorter term, if the symmetric key is compromised, the Curve25519 keys still provide more than sufficient protection.
Networking WireGuard uses only
UDP, Tunneling
TCP over a TCP-based connection can induce a dramatic loss in transmission performance due to the
TCP meltdown problem. Its default server port is UDP 51820. WireGuard fully supports IPv6, both inside and outside of tunnel. It supports only
layer 3 for both
IPv4 and
IPv6 and can
encapsulate v4-in-v6 and vice versa.
MTU overhead The overhead of WireGuard breaks down as follows: This approach ensures consistency and facilitates a smoother transition to enabling IPv6 for the WireGuard peers and interfaces in the future. However, for mobile clients with varying forms of network connectivity and varying MTU across numerous network connections, an MTU of 1280 can be beneficial allowing for IPv6 transport inside the tunnel as that is its minimum allowed MTU, and allow the WireGuard tunnel to function over most forms of connectivity. Hosts often avoid sending packets > 1280 due to
PMTUD reliability. The MTU of a WireGuard interface is determined by the encapsulating, or
outer, IP protocol—not the IP version carried inside the tunnel. When WireGuard packets are transported over IPv4, the outer-header overhead is 60 bytes (20-byte IPv4 header, 8-byte UDP header, and 32-byte WireGuard header). When transported over IPv6, the outer-header overhead rises to 80 bytes. This distinction means that even if a peer is reachable only via IPv4, other peers in the same mesh may connect over IPv6 or through translation mechanisms. Translation increases header size and enforces IPv6’s 1280-byte minimum path MTU, requiring that implementers budget for the 80-byte IPv6 overhead when setting a consistent interface MTU.
Extensibility WireGuard is designed to be extended by third-party programs and scripts. This has been used to augment WireGuard with various features including more user-friendly management interfaces (including easier setting up of keys), logging, dynamic firewall updates, dynamic IP assignment, and
LDAP integration. It is supported natively and by a number of commercial VPN services such as
NordVPN,
IPVanish, and
TunnelBear. Excluding such complex features from the minimal core codebase improves its stability and security. For ensuring security, WireGuard restricts the options for implementing cryptographic controls, limits the choices for
key exchange processes, and maps algorithms to a small subset of modern
cryptographic primitives. If a flaw is found in any of the primitives, a new version can be released that resolves the issue. ==Reception==