WPA2 replaced the badly broken WEP standard in 2004 and quickly became the baseline for wireless security. For thirteen years it held up well. The passphrase-based version most homes use (WPA2-Personal) was vulnerable to offline password guessing if you chose a weak passphrase, but the protocol itself was considered sound. KRACK, short for Key Reinstallation Attack, was different. It targeted a flaw in the WPA2 standard itself, which meant every correct implementation was affected.
The four-way handshake, briefly
When a device joins a WPA2 network, the client and the access point run a four-message exchange called the four-way handshake. Both sides already share a secret (derived from the passphrase or from an enterprise authentication server). The handshake uses that shared secret to agree on a fresh session key, the Pairwise Transient Key, that will actually encrypt the traffic for this session.
The important part is message three. The access point sends message three to tell the client the key is ready, and the client responds with message four and installs the key. Once installed, that key encrypts frames using a counter, called a nonce or packet number, that increments with every frame. The security of the encryption depends on one rule: a given key must never encrypt two different frames with the same nonce.
The reinstallation trick
Wi-Fi is a lossy medium. Messages get dropped. So the standard says that if the access point does not receive message four, it retransmits message three. When the client receives a retransmitted message three, it reinstalls the same key and, critically, resets the nonce counter back to its starting value.
That reset is the whole attack. Vanhoef showed that an attacker sitting between the client and the access point can capture and replay message three at will. Each replay forces the client to reinstall the key and rewind the nonce to a value it has already used. Now the same key is encrypting new frames with nonces that were used before.
WPA2 uses a stream-cipher-style construction (AES in CCM counter mode). The nonce plus the key produces a keystream that is combined with the plaintext. Reuse the nonce and you reuse the keystream. Combine two ciphertexts that share a keystream and the keystream cancels out, leaking the relationship between the two plaintexts. From there an attacker can recover content and, in some configurations, forge and replay packets.
This is the same class of failure that shows up whenever a counter is reused, covered in more depth in our piece on nonce reuse vulnerabilities. KRACK is the highest-profile real-world example: a nonce reset baked into a widely deployed standard.
The worst-case variant
One implementation detail made KRACK far more damaging on certain devices. The Wi-Fi client software wpa_supplicant, used by Linux and by Android 6.0 and later, cleared the key from memory after installing it. When the attacker forced a reinstallation, the client dutifully installed an all-zero key. That turned a partial decryption attack into full traffic decryption on a large fraction of Android phones at the time, with a trivially known key.
For those devices the practical result was that an attacker within Wi-Fi range could decrypt traffic on the local hop. Against a website served over plain HTTP, that meant reading and modifying the page. Against a network login without additional protection, it could mean capturing session data.
What KRACK did not do
It helps to be precise about the limits, because the coverage at the time was alarming.
- It did not recover your Wi-Fi password. The attacker never learned the passphrase or the master key. The network name and password were unchanged after the attack.
- It did not break encryption above the link layer. A connection already protected by TLS (HTTPS) stayed protected. KRACK exposed the Wi-Fi hop, not the end-to-end tunnel running inside it.
- It required proximity. The attacker had to be within radio range and positioned in the traffic path, not sitting anywhere on the internet.
That third point is why KRACK never became a mass-exploitation event on the scale the headlines implied. It was a serious protocol flaw with a narrow physical reach.
The fix and the WPA3 question
The repair was straightforward once the flaw was understood. Patched clients and access points refuse to reinstall a key that is already in use, so the nonce never rewinds. Because the fix could live on either side of the handshake, a patched phone was protected even against an unpatched router, and vice versa. Vendors shipped updates through late 2017 and 2018.
KRACK also became part of the argument for WPA3, which was finalized in 2018. WPA3-Personal replaces the passphrase handshake with SAE (Simultaneous Authentication of Equals, based on the Dragonfly exchange), which resists the offline password guessing that always haunted WPA2-Personal, and it mandates Protected Management Frames. WPA3 was not a direct response to KRACK, and researchers later found separate weaknesses in early SAE implementations (the Dragonblood set of bugs). The honest summary is that WPA3 improved the handshake meaningfully while proving, again, that new protocols carry new bugs. Our WPA3 explainer covers where it stands today.
| Concern | What actually protects you |
|---|---|
| KRACK and future link-layer flaws | Keep clients and routers patched; the fix blocks key reinstallation on either side. |
| Content confidentiality on any network | End-to-end encryption above Wi-Fi (HTTPS, encrypted messaging). This survives a broken local hop. |
| Weak Wi-Fi passphrase | A long random passphrase, or WPA3-Personal, which resists offline guessing. |
| Untrusted public Wi-Fi generally | Assume the network is hostile and rely on the encryption inside your apps, not the network's. |
The lasting lesson
The most useful takeaway from KRACK is not about Wi-Fi at all. It is about where you place your trust. Wi-Fi encryption protects one link: the hop between your device and the access point. It was never designed to protect your data across the whole path to the server you are talking to. When that single link broke, the only thing that stood between users and full exposure was whether the traffic riding on top was independently encrypted.
This is the argument for defense in depth, and specifically for end-to-end encryption. The network you happen to be on should not determine whether your communication is private. A device running an evil-twin access point (covered in evil twin attacks) or a compromised hotel network (see public Wi-Fi security) is functionally the same threat as a KRACK attacker: someone who controls your local link. In every case, the answer is the same. Encrypt above the link, and treat the link as untrusted by default.
Where Haven fits
Haven is built on the assumption that the network is not on your side. Messages and email are end-to-end encrypted on the device before they touch any network, using PGP for email and the MLS protocol (RFC 9420) for group chat. A broken Wi-Fi link, a hostile hotspot, or a future flaw in whatever link-layer standard comes after WPA3 does not expose message content, because the confidentiality never depended on the network in the first place. That is not a claim unique to Haven. It is the property you should demand from anything carrying communication you care about.