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 majordomo at wasabisystems.com