IVs in WEP encryption

Question

First, I'm pretty new to the world of encryption. As I understand it, in WEP, the plaintext and CRC are XOR'd with the IV and the key (or more accurately, the key/stream, which is produced by a pseudo-random generator) to get the resulting ciphertext.

Basically, given two different messages encrypted with the same IV and key, an attacker can XOR both ciphertexts and soon reveal the plaintext.

So, why is the IV sent in plaintext with the message? When the attacker knows the IV, isn't it easier to work out the key and decrypt the messages?

Answer 1

Generally, the security contract for a cipher involving an IV or nonce does not require the IV/nonce to be secret, for the cipher to provide any security. Not only is there no need to keep the IV/nonce secret, but it often provides negligible additional security to do so, and it often enhances security to use a (public, observable) message sequence number as a nonce.

However, it's anyone's guess what ‘design’ might have gone into WEP, and certainly it had no input from any competent cryptographer, who might have alerted them to the stupidity of their design and to the fact that RC4 was $55v$1@mhadg.production.compuserve.com>, 1994-09-15.">broken within 48 hours of its publication, not to mention the plethora of other ways it has been found to broken since then because people kept using it in protocol after protocol despite being broken.

You could change one small part of WEP's cryptography at a time, and the rest would be just as much of a disaster; the only thing to be done with it is to throw the whole thing out and start over.

Answer 2

It must be sent with the message in order to be decipherable to the legitimate decipherer.

The message sent has the IV as the first part. The shared key $K$ is known, so the "packet key" $K'$ is $\textrm{IV} || K$ and this is used to encrypt the data + CRC. The recipient can only decrypt using RC4 if he knows $K'$ too, so he must know the IV as well. After decryption the CRC can be checked. Moreover, in network traffic there often is a counter or per packet identifier that is sent with the data anyway, so using (part of) that data as IV is "free".

An alternative would be to encrypt the IV (3 bytes) with key $K$ and send that. But that's bad for several reasons: we need an extra key setup (relatively expensive in RC4) just for 3 bytes of IV decryption. It also gives an extra attack option for sniffers: one coild build tables for keys and their associated encrypted IV's and if IV's were in any way predictable (often counters, so yes) we'd have an extra off-line attack option. If you don't send the IV at all, a recipient would have to do a $24$ bit brute force over all IV's and possible $K'$'s to detect a packet with the right CRC after decryption but then a packet with an invalid CRC wouldn't ever be deciphered. And it's very slow as well.... Not an option, really.

The problem is not plain IV's but too short IV's and bad "mixing" of IV and $K$. The short IV's give too many collisions, and then regardless of mixing we get packets that are in depth. But the bad mixing (in combination wtih the key schedule of RC4) gave a lot of statistical options to attack.