Learn WireGuard - WireGuard Security Model

#Introduction

Every cryptographic protocol is a set of choices: which algorithms are used, which attacks are handled, and which attacks are deliberately left out. WireGuard takes a radical approach — one set of modern primitives, no cipher choices, and a clearly documented threat model.

Episode 13 dissects the WireGuard security model: the cryptographic primitives that form its raw materials, the threats it successfully handles, and the limitations you must compensate for with layers outside the protocol.

A security model is not just a list of algorithms; it determines where your energy should be directed. After this episode, you should be able to answer a simple question: is WireGuard enough for my scenario, or do I need to add a layer?

#Cryptographic Primitives

#The Four Raw Materials

WireGuard uses only four primitives, all of them curated modern standards:

• Curve25519: an elliptic curve for Diffie-Hellman-based key exchange, fast and resistant to many side channels.
• ChaCha20-Poly1305: authenticated encryption that provides both encryption and integrity in a single AEAD construction.
• BLAKE2s: a fast hash function for deriving keys and mixing handshake material.
• SipHash24: a lightweight hash for the table's internal data structures, not for cryptography.

#Why Only Four

With few primitives, there are no combinations that can be misconfigured. There is no cipher suite menu like in TLS or IPsec, so the surface for implementation errors and configuration errors shrinks drastically. This is part of the "crypto-first" philosophy we discussed in episode 1.

With four primitives, the whole protocol can be audited by a small group of experts, and the result is far more trustworthy than a system with dozens of combinations. This aligns with the historical story in episode 1: security grows from simplicity, not from the number of options.

grep -i -E "aes|avx|sha" /proc/cpuinfo | head -1

The grep -i -E "aes|avx|sha" /proc/cpuinfo command checks the instructions available on your CPU. Instruction support such as AVX accelerates ChaCha20-Poly1305 on many modern CPUs, and we will measure its performance in episode 15.

#Threat Model

#Passive Eavesdropper

An attacker who only intercepts packets gains nothing except ciphertext and minimal metadata. Without the private key and handshake material, there is no way to break the session. Forward secrecy ensures that even if a long-term key leaks later, past sessions remain sealed.

Additionally, because session keys are continually rekeyed as in episode 5, the impact of a long-term key leak can be limited. The combination of forward secrecy and rekeying means a passive eavesdropper has no material for attacking old sessions.

#Active MITM

An active attacker posing as one of the parties is blocked by cryptokey routing: every packet must be implicitly signed with a key matching the peer's public key. An impersonator does not hold the legitimate private key, so its handshake and all its packets are rejected.

What to remember: WireGuard protects the integrity of the connection, not human identity. If an attacker can take over the device holding the private key, all cryptographic protection is meaningless. Device security remains your responsibility.

#DoS Attacks

Flooding handshakes with fake packets is dampened by the cookie mechanism we covered in episode 5. Handshakes are also expensive for the attacker, and the server can rate-limit them without storing large amounts of state.

The cookie mechanism is part of defense in depth: the expensive handshake computation only happens after a cookie is received, making it unprofitable to flood the server with fake handshakes.

#Limitations You Must Complete

#No User Authentication

WireGuard only knows keys, not people. There is no concept of username, password, or user certificate. If two people share one device and one key, they cannot be distinguished. For user identity needs, you need a management layer such as Firezone that wraps WireGuard with authentication.

#No User-Based ACLs

Because identity is key-based, WireGuard's access policy is also key-based. You cannot directly say "this user may access that subnet" — what you can do is arrange AllowedIPs per peer, and who holds that peer's key is managed outside the protocol.

#Traffic Metadata Is Visible

WireGuard hides packet contents, but traffic patterns — when, how often, and how large packets are — remain observable by a passive eavesdropper. To hide these patterns, you need an additional layer such as obfuscation or carrying WireGuard inside another tunnel.

Assessing metadata threats needs context: to a passive eavesdropper, knowing that two parties are communicating can be more valuable than the content of the communication. If your threat profile includes advanced interception, consider adding a layer that disguises patterns, or schedule communications in patterns that are hard to predict.

#Key Management Is Your Responsibility

The protocol does not provide a way to store keys securely, rotate them, or revoke them. All of that is in your hands: encrypted backups, periodic rotation, and peer audits as we covered in episode 12. Also expand that to revoking peers that are no longer used, so the peer table does not accumulate without an owner.

The best pattern is to make key management part of your routine, not an emergency event. Scheduled rotation, periodic peer audits, and tested recovery are habits that prevent crises, not just react to them.

In this way, the protocol's limitations are not frightening weaknesses but clear space for you to work in.

#Assessing the Need for Additional Layers

#Match It to Context

The WireGuard security model is adequate for the majority of VPN scenarios. Additional layers are only needed when:

• Individual user identity must be authenticated.
• Access must be restricted per role and per subnet.
• Traffic patterns must be hidden from eavesdroppers.
• Keys must be managed centrally for hundreds of devices.

For this decision, return to your own threat model: who is the adversary, what are the assets, and what does WireGuard already handle by default?

Good practice is to write your threat model down in a short document, then re-test it whenever your network changes. This document helps the team answer difficult questions consistently, rather than by habit or trend.

Also remember that security documentation is only useful if it is re-read. Schedule periodic reviews, for example every quarter, and update it along with any infrastructure change.

#Closing

Episode 13 completed your understanding of the security model: four curated modern primitives, protection against passive eavesdroppers and active MITM, the cookie mechanism for DoS, and limitations such as the absence of user authentication and ACLs that you must complete yourself.

Key takeaways:

• WireGuard uses Curve25519, ChaCha20-Poly1305, BLAKE2s, and SipHash24.
• A passive eavesdropper only sees ciphertext and traffic patterns.
• Active MITM is blocked by cryptokey routing.
• DoS is dampened by the cookie mechanism and handshake rate limiting.
• There is no user authentication or user-based ACL.
• Key management and backups are your responsibility.

In episode 14 we cover firewall and access control — integrating WireGuard with nftables and iptables, arranging rules through PostUp and PostDown, and applying key-based access control to restrict access between subnets.