Every time a device joins a WPA2 network, it and the access point exchange exactly four EAPOL-Key frames before any actual traffic flows — the 4-way handshake. It's the mechanism that turns a shared passphrase into per-session encryption keys without ever transmitting the key itself, and it's also the exact moment attackers target when capturing traffic to attempt an offline password-cracking attack later. This post covers what each of the four messages actually does and why the design needs all four.
The two keys involved
Before the handshake even starts, both the access point and the client have independently computed the same PMK (Pairwise Master Key) from the network's passphrase and SSID — this happens once and stays the same as long as the passphrase does. The handshake's actual job is deriving a fresh PTK (Pairwise Transient Key) for this specific session, combining the PMK with two random nonces and both devices' MAC addresses — different every time a device connects, even though the underlying PMK never changes.
Message 1: the AP sends its nonce
AP → Client
ANonce (a fresh random value)
Key ACK = 1, Key MIC = 0, Install = 0, Secure = 0The access point generates a random value (ANonce) and sends it, unencrypted — nothing secret has been exchanged yet, so there's nothing to protect at this point. The client now has everything it needs (PMK, ANonce, its own nonce it's about to generate, both MAC addresses) to compute the PTK on its own.
Message 2: the client responds with its nonce and proof
Client → AP
SNonce (the client's own fresh random value) + MIC
Key ACK = 0, Key MIC = 1, Install = 0, Secure = 0The client generates its own random value (SNonce), computes the PTK using both nonces, and sends its SNonce back along with a MIC (Message Integrity Code) computed using the derived key. This MIC is the actual proof: if the client computed the right PMK from the right passphrase, the MIC will be valid; if the passphrase were wrong, it wouldn't match. This is also exactly what an offline dictionary attack tests against — it doesn't need to interact with the network again once it has this message and Message 1's ANonce; it can test candidate passphrases against this MIC entirely offline.
Message 3: the AP confirms and installs
AP → Client
GTK (Group Temporal Key, for broadcast/multicast traffic) + MIC
Key ACK = 1, Key MIC = 1, Install = 1, Secure = 1Having verified the client's MIC from Message 2, the AP now sends the GTK (used for broadcast and multicast traffic shared by every client on the network, separate from the per-client PTK), along with its own MIC proving it holds the same PTK. The Install flag here specifically instructs the client to install the pairwise key and start using it, and Secure indicates the connection is transitioning to encrypted communication.
Message 4: the client confirms
Client → AP
(no new key material)
Key ACK = 0, Key MIC = 1, Install = 0, Secure = 1A final acknowledgment — the client confirms it received Message 3 and has installed its keys. After this, both sides switch to using the derived PTK for all unicast traffic and the GTK for broadcast traffic, and normal encrypted communication begins.
A second, shorter handshake: rotating the group key
The 4-way handshake covered above establishes the pairwise key — unique between one client and the access point. The GTK it also delivers (in Message 3) is shared by every client on the network, used for broadcast and multicast traffic that isn't addressed to one specific device. Because it's shared, it needs periodic rotation — most commonly when a client disconnects, so it can't continue decrypting broadcast traffic after leaving. That rotation uses a separate, shorter 2-way group key handshake: the AP sends the new GTK (encrypted with the existing PTK, since a pairwise key already exists at this point), and the client acknowledges it — no nonce exchange needed, since the pairwise key already established during the original 4-way handshake secures this exchange directly.
Why this handshake is exactly what gets captured for offline attacks
The handshake has to happen in the clear — encryption doesn't exist yet at the point keys are being established, so there's no way to protect the exchange itself. Anything that forces a device to reconnect (it wakes from sleep, moves back into range, or is deliberately knocked offline by a deauthentication frame — a well-known technique specifically for this purpose) produces a fresh, capturable handshake, which is exactly why passphrase strength — not handshake secrecy — is WPA2-Personal's actual line of defense.
Common mistakes
- Assuming a captured handshake alone reveals the passphrase. It only provides the material needed to attempt an offline attack; success still depends entirely on passphrase strength.
- Confusing the PMK and PTK. The PMK is long-lived and passphrase-derived; the PTK is fresh per session and is what the handshake actually negotiates.
- Assuming Message 3's Secure=1 flag means encryption started at Message 1. Everything before Message 4's confirmation is transmitted unencrypted by necessity.
FAQ
Why does the handshake need four messages instead of just exchanging the key directly?
Because neither side can simply send the PTK (Pairwise Transient Key) directly — that would mean transmitting key material in the clear before any encryption exists. Instead, both sides independently compute the same PTK from information they already share (the PMK) plus two fresh random nonces exchanged during the handshake, and the four messages exist specifically to exchange those nonces and confirm both sides actually derived matching keys, without ever transmitting the key itself.
What's the difference between the PMK and the PTK?
The PMK (Pairwise Master Key) is derived once from the passphrase and SSID and stays the same for as long as that passphrase is configured. The PTK (Pairwise Transient Key) is derived fresh for every single connection session, combining the PMK with both nonces and both devices' MAC addresses — which is exactly why capturing one session's handshake doesn't expose another session's actual encryption keys, even though both use the same underlying PMK.
Why is capturing a 4-way handshake so easy to do passively?
Any device reconnecting to a network — waking from sleep, moving back into range, or being deliberately forced to reconnect via a deauthentication frame — triggers a fresh handshake, and it's transmitted in the clear (the whole point of the handshake is establishing encryption, so it can't itself be encrypted). Anyone within radio range with a WiFi adapter in monitor mode can capture it without needing to be connected to the network at all.
Does capturing the handshake mean an attacker has broken the network's security?
No — it only gives them the raw material needed to attempt an offline dictionary or brute-force attack against the passphrase. Whether that attack actually succeeds depends entirely on passphrase strength; a long, random passphrase remains impractical to crack even with a captured handshake in hand.
Does WPA3 still use this same 4-way handshake?
The 4-way handshake for deriving the PTK still exists conceptually in WPA3, but the initial key establishment step that WPA2 does with a straightforward PSK-derived PMK is replaced by SAE (Simultaneous Authentication of Equals) — a fundamentally different exchange specifically designed so that capturing it doesn't hand an attacker anything useful for offline cracking, unlike WPA2's handshake.
Try it yourself
EAPOL Handshake Frame Decoder parses any of these four frames from raw hex and identifies which message it is from its flags, entirely in your browser.