WPA3 Dragonfly Handshake — SAE Explained

Why WPA2's 4-way handshake was replaceable

The WPA2 4-way handshake served two purposes: (1) prove that both parties know the PSK without transmitting it directly, and (2) derive fresh session keys (PTK, GTK) for encrypting data traffic. However, the handshake frames contained sufficient information for an offline dictionary attack — the MIC (Message Integrity Code) is a keyed hash that can be verified against candidate PSKs.

The attack works because the PMK (Pairwise Master Key) is derived deterministically from the PSK and SSID through PBKDF2. An attacker captures the Anonce, Snonce, and MIC from the handshake frames, then tests candidate passwords: for each password, compute PMK, derive PTK, check if the MIC matches. If it does, the password is correct.

This offline verification is possible because the handshake material is transmitted in plaintext (before encryption keys are established). The protocol was designed for mutual authentication but inadvertently exposed the PSK to offline verification — a structural weakness that SAE eliminates.

SAE protocol overview — two phases

Phase 1 (the SAE commit exchange): both the supplicant (client) and authenticator (AP) independently derive a Password Element (PWE) from the password and SSID through a hash-to-curve or hash-to-group operation. Each party generates a secret ephemeral keypair (private scalar 'sa', public element 'commit-scalar') and a mask element 'commit-element'. The commit exchange transmits: commit-scalar and commit-element (both derived from the PWE and ephemeral key).

Phase 2 (the SAE confirm exchange): after receiving the peer's commit-scalar and commit-element, each party computes the shared secret K = sa * (peer_commit_scalar * PWE + peer_commit_element) — a scalar multiplication on the elliptic curve (ECC variant) or modular exponentiation (FFC variant). This produces a cryptographically strong shared secret K that both parties can independently compute.

After Phase 2, the shared secret K is used to derive the PMK through a KDF (Key Derivation Function). The PMK then feeds into the existing 802.11 key hierarchy (PTK derivation via PRF-384 or PRF-512) identical to the WPA2 post-PMK flow.

Password Element (PWE) derivation — hash-to-curve

The PWE is the critical link between the human-memorable password and the SAE protocol. It is computed as follows: PWE = hash-to-curve(SSID || password || counter || extra), iterating a cryptographic hash function until the output maps to a valid point on the selected elliptic curve (or a valid element in the finite field for FFC).

The hash-to-curve operation uses HKDF-extract (SHA-256) to derive a pseudorandom bitstring from the password, then attempts to map it to a curve point. If the mapping fails (the output is not on the curve), the counter is incremented and the operation repeats. This is intentionally expensive — it costs CPU time per authentication.

The PWE derivation cost is the primary reason SAE prevents offline cracking: to test a single candidate password against a captured SAE exchange, an attacker would need to re-derive the PWE and replay the entire commit/confirm exchange for each candidate. This is computationally expensive (milliseconds per attempt) and cannot be parallelized efficiently because the PWE derivation is a sequential hash-to-curve operation.

Elliptic curve vs finite field groups

SAE supports two underlying mathematical structures: Elliptic Curve Cryptography (ECC) and Finite Field Cryptography (FFC). ECC groups (defined by IANA and the Wi-Fi Alliance) include: 19 (256-bit random ECC, NIST P-256), 20 (384-bit ECC, NIST P-384), 21 (521-bit ECC, NIST P-521). FFC groups include: 1 (1024-bit MODP), 2 (2048-bit MODP), 3 (3072-bit MODP).

In practice, WPA3 implementations use group 19 (P-256) by default. Groups 1 and 2 are deprecated due to the Dragonblood downgrade attacks (2019) — modern APs reject them. Group 21 is used in WPA3-Enterprise 192-bit mode.

The group choice affects: (1) key size — P-256 produces 32-byte shared secrets vs P-521's 66-byte; (2) computational cost — P-256 scalar multiplication is ~4x faster than P-521 and ~10x faster than 2048-bit FFC; (3) post-quantum security — ECC groups are only half as secure under Grover's algorithm, while FFC groups are unaffected by Shor's algorithm (but both are weak against a full-scale quantum computer).

Anti-clogging tokens and DoS protection

SAE includes a built-in denial-of-service protection mechanism: anti-clogging tokens. Before processing a commit message, the AP may require the client to solve a hashcash-like proof-of-work. The AP sends a random anti-clogging token, and the client must respond with a token that has a certain number of leading zero bits in its SHA-256 hash.

The difficulty is adaptive — the AP increases the required proof-of-work difficulty when it detects flooding attempts. This prevents an attacker from exhausting AP resources by initiating thousands of SAE handshakes in parallel.

The anti-clogging mechanism does NOT affect legitimate authentication or password recovery. It only impacts attackers trying to DoS the AP. For the intended use of SAE (authenticating a known password), the proof-of-work is negligible (typically <100ms to compute).

Why SAE prevents offline cracking — the math

In WPA2, the PMK is directly verifiable: given a PSK candidate, compute PMK = PBKDF2(PSK, SSID) via 4096 iterations, use it to compute the PTK and verify the MIC from the captured handshake. This is a purely computational operation that can be done offline with zero interaction.

In SAE, the PMK cannot be verified without executing the full commit-exchange protocol. To verify a password candidate: (1) derive PWE (hash-to-curve operation, 5-50ms), (2) generate ephemeral keypair (curve scalar multiplication, <1ms), (3) compute commit-scalar and commit-element (group operations, <1ms), (4) compute shared secret K from peer's commit material (scalar multiplication, <1ms). Total: 5-55ms per candidate.

At 5-55ms per candidate, even a single password verification is slow. Parallel verification is limited because the PWE derivation is sequential — you cannot precompute PWE values for massive numbers of candidates in a dictionary attack. The effective verification rate is ~20-200 candidates per second per CPU core, compared to ~12,000 H/s per GPU core for WPA2 (about 100-600x slower).

WPA3 Transition Mode — the crackable exception

WPA3 Transition Mode (mandatory for WPA3 certification, enabled by default on consumer routers) allows both WPA3 (SAE) and WPA2 (4-way handshake) associations. The AP advertises two AKM suites in its RSN IE: AKM 00-0F-AC:8 (SAE) and AKM 00-0F-AC:4 (PSK). Clients may associate with either.

When a client associates via the WPA2 path, the complete 4-way handshake is transmitted — vulnerable to offline dictionary attack. Since both paths share the same password, cracking the WPA2 handshake reveals the WPA3 password as well.

An attacker can force a WPA3-capable client to downgrade to WPA2 by: (1) deauthenticating the client, (2) sending a crafted beacon that advertises only WPA2 AKM (spoofed AP), (3) the client re-associates via WPA2, exposing the 4-way handshake. This downgrade attack is not a protocol vulnerability — it exploits the transition mode fallback.

Practical implications for WiFi security in 2026

WPA3-only networks (no transition mode) provide genuine protection against password cracking from captured handshakes. The SAE protocol's design eliminates the offline dictionary attack that has been the primary WiFi password recovery method since WPA2 was introduced in 2004.

However, WPA3-only mode requires ALL clients on the network to support WPA3. As of 2026, most IoT devices (cameras, smart plugs, sensors) still use WPA2-only chipsets. This forces home networks to run transition mode, maintaining the WPA2 attack surface.

For WiFi password recovery services: the shift to WPA3 reduces the effectiveness of handshake-based recovery. Services are adapting by focusing on: (1) router admin password recovery (default creds, factory reset, physical access), (2) saved-password extraction from Windows/macOS/iOS/Android, (3) WPA2 handshake capture from Transition Mode networks.

SAE handshake security assessment

1. 1

   Check if the network supports WPA3

   Use Wireshark to inspect beacon frames — RSN IE AKM field. AKM 00-0F-AC:8 = WPA3 SAE.

2. 2

   Check for Transition Mode

   If both AKM 8 (SAE) and AKM 4 (PSK) are advertised, the network falls back to WPA2 — crackable via handshake capture.

3. 3

   Test for downgrade vulnerability

   Send a spoofed beacon without SAE AKM. If clients attempt WPA2 association, transition mode is exploitable.

4. 4

   For pure WPA3 networks

   Offline cracking is not possible. Recovery depends on device-extraction (saved passwords) or router admin access.

5. 5

   Audit group selection

   Ensure the AP rejects groups 1 and 2 (MODP) — accept only group 19 (P-256) or higher. Check with hcxdumptool SAE capture.

Frequently Asked Questions

Related Reading