Re: DOS attack on WPA 802.11?

[Arnold G. Reinhold]

At 4:57 AM +0100 11/19/02, Niels Ferguson wrote:

At 21:58 18/11/02 -0500, Arnold G Reinhold wrote:

...

Third, a stronger variant of WPA designed for 11a could also run on
11b hardware if  there is enough processing power, so modularization is
not broken.

But there _isn't_ enough processing power to run a super-Michael. If there
were, I'd have designed Michael to be stronger.

I'm not sure that is true for all existing 802.11b hardware. And vendors of new 802.11b hardware could certainly elect to support the stronger variant of WPA.

Maybe you are suggesting is to add yet another cryptographic function; the
current Michael for existing hardware and a super-Michael for newer 802.11a
hardware. Developing super-Michael would cost a couple of month and a lot
of money. I would consider that a waste of effort that should have been
spent on the AES-based security protocols. That is where we are going, and
we need to get there ASAP. It is perfectly possible to design 802.11a
hardware today that will be able to implement the future AES-based security
protocols. That is what software updates are for.

That is what I am suggesting. If a stronger version of Michael is too expensive to develop, there is still the option of using a standard message authentication function, say an HMAC based on MD5 or an AES solution. I spoke to several 802.11a/g chip-set vendors at Comdex and they seem to be allowing extra processing power to support 11i. Intersel said they were using 20% of available MIPS.

...

[regarding my suggestion to rotate the Michael output words in a key dependant way:]

[...]


Those are standard design questions. I looked at better mixing at the end
of the Michael function and decided against it. It would slow things down
and the attack that changes the last message word and the MIC value had
much the same security bound as the differential attack that does not
change the MIC value. There is no point in strengthening one link of the
chain if there is another weak link as well. Of course, this isn't how I
normally design cryptographic functions, but Michael is a severely
performance-limited design.

[...]

I have responses to your concerns about using SHA and the issue of re-keying, but you point out:

It would be easier just to ask
for 128 key bits from the key management system. It has a PRF and should be
able to do it.

That would be fine. You only need ten additional keying bits for arbitrary rotation of the two output words. Maybe an additional bit to optionally swap the words. This only adds a few instructions per packet.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]