A protocol document, not a product review
WireGuard is the protocol behind many consumer VPN apps, and providers often describe it as “modern” or “proven”. The project’s own website has pages on formal verification and on known limitations, which give a more precise picture. This article summarises those pages and the project’s home page. They are statements by the project, so they show what its authors claim and cite, and they are not independent reviews. They concern the protocol, not any VPN provider’s service. This site’s article on VPN protocols compares WireGuard with OpenVPN and IKEv2.
What the project says about design
The home page describes WireGuard as a simple, fast and modern VPN using state-of-the-art cryptography, and says it aims to be simpler and leaner than IPsec. It lists the cryptographic components as the Noise protocol framework, Curve25519, ChaCha20, Poly1305, BLAKE2, SipHash24 and HKDF, and says the design has been reviewed by cryptographers. It says the protocol is meant to be implemented in very few lines of code so that it can be comprehensively reviewed by single individuals, in contrast with much larger codebases. These are design goals and self-description.
What has been formally verified
The Formal Verification page says WireGuard has undergone several kinds of verification covering the cryptography, the protocol and parts of the implementation. The protocol has been verified in the symbolic model with the Tamarin tool, which the page says means there is a security proof of the protocol. The listed properties are correctness, strong key agreement and authenticity, key-compromise impersonation resistance, unknown key-share attack resistance, key secrecy, forward secrecy, session uniqueness and identity hiding. The page says the work was joint and that the accompanying paper is a draft with the main results in place. It also says the Tamarin model is open source and can be re-run for independent verification.
The page lists further efforts. A computational proof in the eCK model, by Dowling and Paterson, proves a variant of the protocol described as morally equivalent, because the key confirmation message sits in the transport layer and does not fit that model cleanly. A thesis by Lipp constructs a mechanised computational proof of the entire protocol, including transport data messages, using CryptoVerif. The Noise Explorer project models the relevant Noise pattern in ProVerif. For implementation, WireGuard uses Curve25519 code from verified libraries.
What the known limitations page says
The Known Limitations page opens by saying that WireGuard, like all protocols, makes trade-offs. On deep packet inspection, it says WireGuard does not focus on obfuscation and that obfuscation should happen at a layer above. It says WireGuard explicitly does not support tunnelling over TCP, because of poor TCP-over-TCP performance. It notes that hardware support for its cipher, ChaCha20-Poly1305, is not overwhelming, though software speed is generally adequate.
Some entries concern security properties. On roaming, the page says that an active attacker in the middle could replace source addresses, though packets remain indecipherable. On identity hiding and forward secrecy, it says that compromise of a responder’s private key together with a traffic log of earlier handshakes would let an attacker work out who sent handshakes, though not what data was inside them, and it lists rotating keys as a mitigation. It says WireGuard is not post-quantum secure by default, though a pre-shared key can add a layer of post-quantum secrecy. It also notes that the system time is used as a monotonic counter, so a hostile adversary controlling the clock could cause problems, and that routing loop detection has issues.
How to read the two pages together
The verification page and the limitations page describe different questions. The first says what has been proved about the protocol’s handshake and data exchange under stated models. The second says what the design leaves to other layers or accepts as trade-offs. A proof in a model covers the properties listed in that model. The limitations page says the design does not focus on obfuscation and is not post-quantum secure by default.
For readers comparing providers, the practical point is that these pages tell nothing about server operation. Whether a provider keeps logs, who owns its servers, how it manages keys and what jurisdiction it operates in are provider matters, covered in this site’s articles on logging policies and audits and obfuscated servers.
Post-quantum claims
Because the project says WireGuard is not post-quantum secure by default, a provider that advertises quantum resistance is describing something added to the base protocol, such as a pre-shared key arrangement or a separate handshake. The project describes running a post-quantum handshake on top of WireGuard and inserting the resulting key into the pre-shared key slot as the best bet. What a specific provider has implemented needs to be checked in the provider’s own documentation, and the site’s article on post-quantum claims covers how to read them.
The bottom line
The WireGuard project says its protocol has been formally verified in several models and lists the properties proved, and it separately lists known limitations including no obfuscation, no TCP mode, no default post-quantum secrecy and a handshake identity-hiding caveat. These are the project’s own statements about a protocol. They do not verify any provider’s service, logging or server practices, which need separate evidence.