Ho hum. Not a single argument that was not completely predictable. Oh well, guess I'll have to restate the obvious for your benefit.

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

That's a non-trivial effort. Do you think the average script kiddie is going to take their wireless-equipped laptop, with 45GB worth of storage, and go sit within range of the target network for 400 hours, and then apply all the compute power to crack the keys? Dream on. Yes, some people can do this, but those are specialized organizations devoted to this kind of task - not random script kiddies.

Do you understand the term "script kiddie" at all?

Yes, I do, thanks very much for asking. Do you? One of the things about script kiddies that you seem to have missed is that the programs they like to use are relatively easy to write and don't care very much about the exact flavor of the underlying hardware. The "confusing the firmware" exploit we're talking about would have to be repeated for every hardware/firmware combination, and would not be at all easy to write. Half of this hardware doesn't even work on Linux due to lack of driver support. Do you really think more skill and effort will be applied to "confusing the firmware" than has been to unconfusing it and getting it to work? Again, dream on.

Of course, you're right that all it takes is one person to write the program and thousands to use it, but it might still take a while before that one person gets done. With a responsible approach to security, it might have taken them long enough that the vendors would already have plugged the holes by the time the exploit code was ready.

Your hope that equipment manufacturers address this problem is probably misgiven

That's your opinion. Please back it up.

Do you really think it's that hard for vendors to incorporate a 4096-bit cryptographically secure certificate into the firmware image, such that the card will refuse to operate if the certificate is invalid? Think again. I've worked on firmware, and this is the easiest thing in the world for them. Lots of cards have to decompress their firmware as part of the bootstrap procedure anyway; once you're decompressing, it's trivial to add validation. There is no need for the "hardcoded drivers" (what an absurd concept) or other strawmen you suggest.

However, I do know that if this protocol was indeed opened up to peer review as you seem to suggest (without any evidence)

It's an IEEE standard, moron. Do you know what that means? The IEEE goes to extraordinary lengths to solicit and incorporate input from interested parties, many of whom I'm sure are pretty well qualified in their fields. We're not talking about some obscure closed trade group here. IEEE standards are in many ways more open than the not-really-standards of open source. Without IEEE standards we probably wouldn't be talking. How do you think your packets get to slashdot? In large part you owe thanks to IEEE for that.

It's your claim, that the process was somehow not open, that is absurd and that requires proof. Get to it.

Frankly, I can't believe that any serious peer review wouldn't flag the problems....

You just don't know anything about peer review, do you? How many of these sorts of activities have you participated in? The fact is that when you're dealing with complex new technology people sometimes make mistakes. Sometimes the mistakes are real howlers in retrospect. That's life. How many problems do you suppose these guys anticipated and dealt with that you would have flubbed if you'd been in their place? It's really easy to jeer from the peanut gallery, with full benefit of hindsight, but really people who do that are just being pricks.

This is so beyond ludicrous I'm not even going to touch it.

No, really, try to give us a responsible rebuttal, instead of trying to substitute sneering for reasoning. Try, anyway. What you dismissed so flippantly is actually a very hot issue among security professionals: who gets to find out first?

Now, I knew when I suggested it that the "tell the vendors" approach wouldn't be very popular here on ScriptKiddieDot, but that doesn't make it a troll (and neither does calling it one). It's worth considering how this audience differs from the Real World. For one, the attitude here is "openness at all costs". There's no room allowed for discretion or careful handling of delicate issues. No, I'm not talking about "security through obscurity" because that never works. What I'm talking about is giving the vendors a reasonable timeframe in which to fix problems before letting every black hat in the world have the info. Let's face it, for every white hat on this site there are probably a hundred black hats, and I doubt that there's a single person involved in this discussion in a position to do good rather than harm with this information. How do you think it benefits anyone but the script kiddies to publicize this problem in this fashion? It doesn't help the problems get fixed any faster, it just maximizes the damage that gets done before the problem is fixed. Screw your "information wants to be free" dogma, and think about social implications for once.

In case you missed it the first time, and the second time, let me repeat a third time: I agree that there's cause for concern in this. Nobody's disputing that. What pisses me off is that people are trying to enhance their own images by panicmongering. The actual security threat here has not been shown to be effectively distinguishable from zero, and yet these people are acting like any semi-literate cracker might already have everyone's credit card numbers. Believe me, we're all threatened much more by existing security problems in the wired network than by any implications of these findings. If there's one thing that's obvious from all this, it's that the biggest security problem is people not even using the security facilities available to them.