--- key: "icdp-case-wep-2001" title: "WEP: RC4 key reuse and weak IVs" url: "https://softwaresecurity.com/domains/identity-crypto/encryption/wep-rc4-key-reuse/" api: "https://softwaresecurity.com/api/v1/articles/icdp-case-wep-2001.json" domain: "identity-crypto" topic: "Identity \u0026 cryptography" type: "Case study" identifiers: ["CWE-323","CWE-327","CWE-353","A04:2025","V11.3.3","V11.3.4"] tags: ["Encryption","Historical cryptographic attacks"] stages: ["design","build"] roles: ["developer"] license: "CC-BY-4.0" license_url: "https://creativecommons.org/licenses/by/4.0/" code_license: "MIT" --- # WEP: RC4 key reuse and weak IVs Separate WEP’s repeated-keystream failure, weak-IV key recovery, and unkeyed integrity weakness through a concrete two-packet exercise. Canonical URL: https://softwaresecurity.com/domains/identity-crypto/encryption/wep-rc4-key-reuse/ ## In short 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 - Date: 2001-01-30 to 2001-08 - 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 1. 1997: The first IEEE 802.11 standard defines WEP. 2. 2001-01-30: Nikita Borisov presents the WEP design flaws at the Mac Crypto Workshop. 3. 2001-07: Borisov, Goldberg and Wagner present Intercepting Mobile Communications at ACM MobiCom 2001. 4. 2001-08: Fluhrer, Mantin and Shamir present the RC4 key-scheduling weakness and its WEP key-recovery attack at SAC 2001. 5. 2002: Stubblefield, Ioannidis and Rubin publish their passive recovery of a production network’s 128-bit WEP key at NDSS 2002. 6. 2018-06-25: The Wi-Fi Alliance introduces WPA3, which disallows outdated legacy protocols. ## Verify it 1. Export every access point and controller profile and confirm none enables WEP or TKIP. 2. Try to join each network with a WEP-only or TKIP-only client and confirm association fails. 3. Confirm legacy-device networks cannot reach internal services. 4. In your own encrypted formats, confirm nonce uniqueness per key and authentication with a MAC or AEAD tag. ## 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. Audience: Engineers who design encrypted formats or manage wireless networks, and reviewers who assess nonce and integrity design. Before you start: - Understand XOR cancellation and why an IV is not a secret. Time: About 19 minutes: 5 to read and 14 for the exercise ## Several design failures combined in the same frame format WEP 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. ## Small IV space and linear integrity made local fixes inadequate 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. ## Nonce allocation, authentication, and replacement are separate tasks 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. ## What should you do today? - 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/. ## What a two-packet calculation can establish 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 material ```text 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. Worked answer: 48 XOR e2=aa; 49 XOR f2=bb. Thus Z=aa bb. ### 2. Read the second segment Compute P_B=C_B XOR Z. Worked answer: 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. Worked answer: 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. Deliverable: A two-byte plaintext derivation and a three-part decommissioning acceptance record. Scope: Synthetic XOR values demonstrate reuse only. They neither implement WEP nor recover an RC4 key, and they require no wireless transmission. Articles and teaching material: CC BY 4.0. Original executable code: MIT. Attribution: Software Security. ## Sources - [Borisov, Goldberg and Wagner: Intercepting Mobile Communications (2001), archived copy](https://web.archive.org/web/20200709165058/http://people.eecs.berkeley.edu/~daw/papers/wep-mob01.pdf). ACM MobiCom 2001. - [Stubblefield, Ioannidis and Rubin: Using the FMS Attack to Break WEP](https://www.ndss-symposium.org/wp-content/uploads/2017/09/Using-the-Fluhrer-Mantin-and-Shamir-Attack-to-Break-WEP-Adam-Stubbefild.pdf). NDSS 2002. - [Wi-Fi Alliance: Wi-Fi security (WPA3)](https://www.wi-fi.org/security) - [Berkeley ISAAC: Security of the WEP algorithm (FAQ), archived copy](https://web.archive.org/web/20261004064411/http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html) - [Fluhrer, Mantin and Shamir: Weaknesses in the Key Scheduling Algorithm of RC4](https://link.springer.com/chapter/10.1007/3-540-45537-X_1). SAC 2001. - [Wi-Fi Alliance introduces Wi-Fi CERTIFIED WPA3 security](https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-introduces-wi-fi-certified-wpa3-security). 25 June 2018.