The formatting in the original was pretty messed up by the ever-incompetent Dr. Handelman (who apparently never heard of the blockquote tag, or about proper nesting of HTML elements). I've tried to fix it up as best I can without altering the content.

"IV" is "initialization vector" and is the same as what is elsewhere called a "salt". The IV is 24 bits; in a previous paragraph the authors had calculated that for a access point an IV is likely to get reused after about five hours. From this we're apparently supposed to conclude that it's a trivial matter to store every packet until an IV collision occurs, and then use the contents of both packets to recover plaintext. They even seem to be aware that two packets often won't be enough, but fail to mention that you need to save and search another five hours' worth of peak-bandwidth traffic to get anywhere in that case.

Well, assuming the numbers they do (i.e. 1500 byte packets), it takes only 11 Mbps * 18000 seconds = 198 Gb = 24.75 GB of storage space to get a collision in a worst case scenario. But more important, there's no reason to save everything as you go along.

Instead, you just do something like the following. Assume it takes 10 IV collisions to be reasonably assured of computing plaintexts by statistical analysis (this may be generous, considering the redundancies in most of the packets--TCP headers, easily guessed content, etc.). Then you can just build a table for the IV space one portion at a time: say one-eighth at a time. In other words, first you just store all the packets with IVs in the range 0-1x2^22 until you can statistically analyse them and build an IV->cipherstream table for all those IVs. Assuming 10 messages for each IV, this takes about 31 GB. When you're done with that, throw out all those old packets and start on IV range 1-2x2^22, and so on. As they pointed out in their summary, it only takes 15 GB to store the entire IV->cipherstream table. Thus we have total expected storage requirements of ~45 GB, and a total running time of 400 hours to decrypt all future traffic on the network. Moreover, we can start decrypting all the packets with IVs we've already "solved" as soon as we solve them.

This is entirely feasible, but it isn't even the half of it. As they suggest, a much better solution to this problem is to use an active, chosen plaintext attack. That is, the attacker can send a known packet from the outside to a machine on the wireless network; the network will encrypt the packet and send it to that machine, along with its IV in plaintext. The attacker merely needs to intercept that packet (a problem, of course, is knowing which packet it is, although this is solvable with unusual choice of destination machine, etc.) and suddenly he has solved that IV, with no statistical analysis necessary. With this method, we only need 15 GB of storage space (for the table) and enough time to send messages which will be encrypting with every different IV. The latter requirement is going to take a real long time, of course, but as a way to attack, say, 95% of the IVs this is very efficient.

we have been able to successfully intercept WEP-encrypted transmissions by changing the configuration of the drivers. We were able to confuse the firmware enough that the ciphertext (encrypted form) of unrecognized packets was returned to us

I would say that this is likely to be well beyond the capabilities of most script kiddies, and is probably pretty easy for 802.11b equipment vendors to address.

Do you understand the term "script kiddie" at all?? The point of a script kiddie is that he doesn't have to know how to write modified drivers, only how to download them and install them. Hence "script"; they're running someone else's program. And in any case, modifying drivers and even modifying hardware ought not to be beyond the skills or resources of lots of corporate espionage outfits.

Your hope that equipment manufacturers address this problem is probably misgiven; doing so would seem to require them to replace software drivers with hardcoded ones, or at least insert another layer of encryption both inside the hardware and in their drivrs. I submit that both possibilities are very unlikely, and that in any case anyone with deep pockets can build their own 2.4 GHz reciever without too much trouble.

Yeah, like there have never been any problems discovered in crypto products from the self-appointed experts. Uh huh.

Of course there have been, though rarely such softball errors as these. The recently reported vulnerability with the extra decryption keys in PGP, while quite significant, was an implementation error, not an error in the spec itself. And the vulnerabilities found in crypto protocols by the real experts tend to be rather esoteric and impractical ones, and then mainly on entirely new ciphers, not on a spec for piecing together old ones.

In any case, the point is that they are (ideally) found *before* any products using the protocol are put into place. It's called "peer review", perhaps you've heard of it.

"During the design process, the crypto community wasn't invited to participate," says Goldberg, now chief scientist at Zero Knowledge Systems Inc., a privacy-software firm in Montreal.

That's a pretty inflammatory statement, and apparently not far from being an outright lie. It was irresponsible (or possibly venal) of Ian Goldberg to make such a statement, and doubly so for WSJ's Jared Sandberg. As I said before, there is a matter for serious concern here, but the scaremongering from these people is not helping.

I don't know the history here, so I can't comment. However, I do know that if this protocol was indeed opened up to peer review as you seem to suggest (without any evidence), then something went horribly wrong; for some reason, either everyone missed these rather obvious flaws, or, more likely, no one showed up to review it. The point is, offering something for "peer review" and then assuming it's secure after no one shows up to review it is obviously not good practice. Frankly, I can't believe that any serious peer review wouldn't flag the problems inherent in using RC4 with a linear checksum algorithm, or with layering an encryption scheme on such a tiny (24 bit!) IV space.

The right thing to do would have been to alert the equipment manufacturers, discreetly, and let them decide how they want to alert their customers.

This is so beyond ludicrous I'm not even going to touch it. The rest of your post seems to indicate that you're not a troll, but this makes one wonder.