Understanding the WireGuard protocol

WireGuard is an open-source VPN tunnel protocol and implementation started by Jason A. Donenfeld around 2015 and merged into the mainline Linux kernel with version 5.6 in 2020. Its goal is explicit: an encrypted tunnel that is secure, fast and easy to audit, with as little code and as few configuration knobs as possible. The TP VPN apps for iOS and Android use this protocol exclusively. This article explains how it works and how it differs from older protocols.

Design principle: less is more

Older VPN protocols typically negotiate between several encryption algorithms, hash functions and key-exchange methods, which means many options and large implementations. WireGuard takes the opposite approach:

• A fixed cipher suite. The protocol uses one set of well-studied primitives and never negotiates algorithms. If a primitive is ever found weak, the remedy is a new protocol version, not a runtime downgrade.
• Silent by default. A node never replies to a packet that fails authentication. To a network scanner, a WireGuard server looks the same as no server at all.
• Public keys as identity. Each peer is identified by a Curve25519 public key; there are no certificates, usernames or passwords.
• Stateless roaming. A peer may change its IP address at any time; as long as packets authenticate, the tunnel continues.

The Noise-based handshake

WireGuard's handshake uses the IK pattern from the Noise protocol framework with these primitives:

The handshake takes a single round trip: the initiator sends one message containing an ephemeral public key and its encrypted identity, the responder replies with one message, and both sides derive the session keys. Handshake messages carry a TAI64N timestamp to defeat replay attacks, which is why a device whose clock has been set far back cannot connect. Against flooding, a server under load may require the initiator to present a cookie derived from its address before it spends any computation on an unverified request.

Session keys are renegotiated roughly every two minutes and rotated after a fixed number of packets, and old keys are discarded immediately. Even if a long-term private key leaked in the future, past sessions could not be decrypted: this property is forward secrecy.

The key model and cryptokey routing

WireGuard binds each public key to a set of allowed IP ranges, a mechanism called cryptokey routing. When a packet decrypts successfully, the implementation checks that its inner source address falls within the ranges allowed for that key; when sending, it looks up the destination address to decide which peer's key to encrypt with. Identity and routing become a single table, and no separate access-control layer is needed.

In TP VPN, the key pair is generated locally when the app first registers a device. The private key is written only to the iOS Keychain or the Android Keystore, and the server stores just the public key. Every device has its own pair; removing a device revokes its public key and the tunnel stops working. The tunnel configuration is delivered by the app automatically, so there is never a file to import.

Code size and auditability

The original Linux kernel implementation of WireGuard was about four thousand lines of code, whereas implementations of older protocol stacks are typically one to two orders of magnitude larger. A small codebase means a security researcher can read all of it in a reasonable time, bugs are easier to find and fix, and the attack surface is smaller. The protocol has also been formally verified and analysed in several academic papers, which is a large part of why it was accepted into the mainline kernel.

Performance and battery use

• In-kernel forwarding. On Linux servers, packets are encrypted, decrypted and forwarded inside the kernel, avoiding repeated copies between user space and kernel space.
• Lightweight cryptography. ChaCha20-Poly1305 performs well on mobile processors without dedicated hardware acceleration and is gentle on the battery.
• UDP transport. The tunnel never wraps TCP inside TCP, so there is no double-retransmission penalty.
• Seamless network changes. Switching from Wi-Fi to mobile data changes the device's address but not its identity, so the tunnel resumes in place without a new sign-in.
• No idle overhead. With no traffic, WireGuard sends nothing (unless keepalives are configured) and the device can sleep normally.

Actual battery consumption depends mostly on how much data you transfer, not on the tunnel itself.

Comparison with older protocols

The comparison below concerns protocol design only, not any particular product:

Older protocols are not insecure; they have been tested in corporate networks for decades. The difference is that WireGuard reaches the same or higher security goals with far fewer parts, at the cost of less flexibility.

Limitations and caveats

• WireGuard uses UDP only. On networks that allow only TCP or heavily restrict UDP, a connection may not be possible; try a different network in that case.
• The protocol does not hide the fact that WireGuard is in use; its goal is to protect content, not to disguise the shape of traffic.
• Because the handshake relies on timestamps, keep the device clock set automatically.

How TP VPN uses WireGuard

TP VPN offers WireGuard only and does not maintain several protocols side by side in the app. Concentrating on one widely audited protocol keeps configuration simple, behaviour predictable and the scope of any security assessment clear. Server nodes forward in the Linux kernel, and the app reconnects with exponential backoff when a tunnel drops. Details are on the WireGuard protocol feature page.

Further reading

• What is a VPN
• What "no activity logs" really means
• Connection troubleshooting
• Trust Center