WEP failed in several ways at once: its 24-bit IV made RC4 keystreams repeat, weak IVs leaked the shared key, and its CRC-32 checksum let attackers alter packets. Today, allow only WPA3, or WPA2 with AES-CCMP during a transition, and remove WEP and TKIP from every access point and client profile. In your own protocols, never reuse a nonce under one key and never use a checksum as authentication.
- A 24-bit IV space repeats quickly, and a repeated IV under one key repeats the RC4 keystream.
- Two packets with the same keystream reveal the XOR of their plaintexts without the key.
- The FMS weak-IV attack recovered the shared key itself, a different failure from keystream reuse.
- CRC-32 detects accidents, not attackers; encrypting it does not make it a MAC.
- WPA3 is mandatory for Wi-Fi CERTIFIED devices; WEP and TKIP should be absent everywhere.
Incident at a glance
- Dates
- to
- Category
- Cryptographic weakness
- Organizations
- IEEE 802.11 working group
- Wi-Fi Alliance
- Impact
- WEP, the original 802.11 Wi-Fi encryption, repeated RC4 keystreams, leaked its shared key through weak IVs and let attackers alter packets undetected. A passive attacker could recover a 128-bit WEP key from captured traffic.
- How it was found
- Academic analysis: Borisov, Goldberg and Wagner on the protocol design, Fluhrer, Mantin and Shamir on RC4 key scheduling, and Stubblefield, Ioannidis and Rubin, who implemented the key recovery.
Timeline
- The first IEEE 802.11 standard defines WEP.
- Nikita Borisov presents the WEP design flaws at the Mac Crypto Workshop.
- Borisov, Goldberg and Wagner present Intercepting Mobile Communications at ACM MobiCom 2001.
- Fluhrer, Mantin and Shamir present the RC4 key-scheduling weakness and its WEP key-recovery attack at SAC 2001.
- Stubblefield, Ioannidis and Rubin publish their passive recovery of a production network’s 128-bit WEP key at NDSS 2002.
- The Wi-Fi Alliance introduces WPA3, which disallows outdated legacy protocols.
- Export every access point and controller profile and confirm none enables WEP or TKIP.
- Try to join each network with a WEP-only or TKIP-only client and confirm association fails.
- Confirm legacy-device networks cannot reach internal services.
- In your own encrypted formats, confirm nonce uniqueness per key and authentication with a MAC or AEAD tag.
- Applies to
Historical WEP design analysis. Modern Wi-Fi configuration needs separate protocol-specific guidance.
- Part of
- Collection: case studies
Tested fixes: the vulnerable code, the fix, a plausible fix that still fails, and the regression tests that tell them apart.
Learning goals and prerequisites
What you will learn
- Distinguish repeated-keystream exposure from FMS key recovery.
- Explain why CRC does not authenticate encrypted data.
- Evaluate partial WEP fixes against distinct failure mechanisms.
Before you start
Engineers who design encrypted formats or manage wireless networks, and reviewers who assess nonce and integrity design.
- Understand XOR cancellation and why an IV is not a secret.
Refresh first: RC4 keystream bias
Go to the guided practiceWEP formed an RC4 per-packet key by combining a transmitted 24-bit initialization vector with a shared secret. It encrypted the payload and an integrity check value derived from CRC-32. The IV was public, as IVs often are; the problem was the small reuse space and its interaction with RC4 key scheduling, combined with an integrity check that was not a keyed authenticator.
When two packets reuse the same IV under the same shared secret, they reuse the same keystream Z. Their ciphertexts obey C₁=P₁ XOR Z and C₂=P₂ XOR Z, so C₁ XOR C₂=P₁ XOR P₂. Knowing a plaintext segment in one packet exposes the matching segment in the other. Recovering those bytes does not require recovering the shared key.
The Fluhrer–Mantin–Shamir attack concerned a different step: particular IV-related RC4 key-scheduling behavior leaked statistical information about the shared secret. Stubblefield, Ioannidis, and Rubin demonstrated practical WEP key recovery using that idea. RC4’s later keystream-bias attacks are a separate problem, covered at /domains/identity-crypto/encryption/rc4-keystream-bias/. Treating all 2001 WEP research as one identical attack obscures the difference between reuse-based plaintext relations and weak-IV key recovery.
A 24-bit IV offers 16,777,216 values. A perfect counter eventually wraps; random selection encounters collisions much sooner, around the square root of the space. Reboots, multiple senders sharing a secret, and implementation choices can make reuse still worse. The key context matters: the same IV under a genuinely different key does not imply the same stream.
CRC-32 detects accidental changes, but its linear structure allows predictable relationships between changes to data and changes to the checksum. Encrypting both does not turn the CRC into a keyed MAC. An attacker can manipulate a stream-encrypted message and its checksum without knowing the original plaintext in full. Packet replay is a further protocol issue that an encrypted checksum alone does not address.
The Berkeley work presented at MobiCom in 2001 analyzed WEP’s design, including confidentiality and integrity weaknesses. The later practical FMS implementation report gave evidence for the key-recovery route. These publication events are not a claim that every observed WEP packet was exploited, or that all product implementations had exactly the same traffic requirements.
A longer shared WEP secret does not enlarge the transmitted IV field or replace CRC with cryptographic authentication. Avoiding a subset of weak IVs also leaves repeated streams, the small space, and integrity problems. A repair must replace the protocol with a supported wireless security design, migrate clients, and remove WEP compatibility access paths.
This historical case applies to modern application records through its failure categories. A good cipher can be undermined by nonce reuse, as the AES-GCM nonce lab at /labs/nonces/ shows. A checksum is not authentication. Shared credentials enlarge the scope of compromise and complicate rotation. These are transferable design lessons, but they do not mean modern wireless protocols are simply WEP with a larger key.
For a legacy decommissioning decision, inventory actual access points, guest networks, embedded clients, and bridges. A secure primary network does not compensate for an old WEP segment bridged into the same trusted network. Isolation can reduce immediate reach while replacement proceeds; it does not restore the confidentiality or integrity of the radio link.
- Configure networks for WPA3-Personal (SAE) or WPA3-Enterprise; use WPA2 with AES-CCMP only as a transition mode.
- Remove WEP and TKIP from every access point, controller template and client profile, including guest and IoT networks.
- Put devices that only support legacy security on an isolated network with no route to internal services, and plan their replacement.
- In application protocols, use an AEAD with a unique nonce per key and a real MAC, as described in the AEAD record guide at /domains/identity-crypto/encryption/authenticated-record-design/.
A protocol inventory showing WEP enabled establishes exposure to an obsolete design. A captured repeated IV identifies potential repeated-keystream conditions only when the shared-key context and frame processing match. Recovering a supplied toy plaintext using XOR illustrates the algebra, not a real key-recovery experiment.
After replacement, confirm a supported client joins and reaches its intended service, a WEP-only attempt cannot associate, and the old network is absent from every radio and management profile. Verify segmentation separately. A screenshot of a new network name does not prove removal of the previous configuration.
Guided practice
Two synthetic WEP-like packet segments share an IV and key. Recover the second plaintext segment.
Supplied scenario material
IV_A=IV_B=01:02:03; shared key identifier=K7.
Known P_A = 48 49 (ASCII HI).
C_A = e2 f2.
C_B = f8 fe.
All arithmetic is bytewise XOR; no RC4 execution is needed.1. Recover the shared stream segment
Compute Z=P_A XOR C_A.
Expected result and reasoning
48 XOR e2=aa; 49 XOR f2=bb. Thus Z=aa bb.
2. Read the second segment
Compute P_B=C_B XOR Z.
Expected result and reasoning
f8 XOR aa=52 and fe XOR bb=45: bytes 52 45 are ASCII RE.
3. Test the inference boundary
Repeat the reasoning if packet B instead used a different independent key K8; then assess replacing CRC with a longer CRC.
Expected result and reasoning
Different keys remove the supplied basis for equal Z, so RE is no longer justified. A longer unkeyed CRC remains an error-detection function and is not a cryptographic authenticator.
Synthetic XOR values demonstrate reuse only. They neither implement WEP nor recover an RC4 key, and they require no wireless transmission.
Save a draft on this device to resume later. Automatic saving begins after you choose Save. Drafts are never sent by this application; use synthetic data.
No draft saved on this device yet.
Sources & further reading
The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.
- Borisov, Goldberg and Wagner: Intercepting Mobile Communications (2001), archived copy. ACM MobiCom 2001.
- Stubblefield, Ioannidis and Rubin: Using the FMS Attack to Break WEP. NDSS 2002.
- Wi-Fi Alliance: Wi-Fi security (WPA3)
- Berkeley ISAAC: Security of the WEP algorithm (FAQ), archived copy
- Fluhrer, Mantin and Shamir: Weaknesses in the Key Scheduling Algorithm of RC4. SAC 2001.
- Wi-Fi Alliance introduces Wi-Fi CERTIFIED WPA3 security. 25 June 2018.
Reference information
- SDLC phase
- DesignDevelopment
- Role
- Developers
- ASVS 5.0.0 requirements
- v5.0.0-11.3.3 · v5.0.0-11.3.4