At 21:58 18/11/02 -0500, Arnold G Reinhold wrote: >Modularization is a poor excuse for shipping a cryptographically weak >product.
The current alternative would be to ship _no_ 802.11a products. That might be intellectually preferable, but that's not how the real world works. >Second in this case the PHY layer does affect a MAC layer >feature. 802.11a is much faster than 11b. That makes Michael >even more vulnerable to attack. If Michael is subject to one forged >packet per year on 11b, it is vulnerable to one every 10 weeks or so in >11a. Well, no. The time it takes for an attacker to forge a Michael packet consists mostly of the 1-minute delays of the countermeasures. Using a faster PHY protocol doesn't speed up the attack, so Michael has the same strength for 802.11a and 802.11b. >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. 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. >As for shipped hardware, does anyone know that it couldnot run with a >stronger version of Michael? And a few shipped units, is far less >justification than the 10's of millions of 802.11b units out there. There are millions of 802.11b chips out there. I don't know how many 802.11a chips there are in the field, but certainly a few orders of magnitude fewer. Creating a significant slow-down for millions of fielded units is unacceptable. The whole point of WPA is to work well on fielded units. New hardware should implement the AES-stuff. [...] >A marginal improvement on a marginal algorithm can be worthwhile. It does >break up one attack mode at negligible cost. Aah, but the cost isn't negligible. The per-packet overhead is significant for small packets, and adding more computations for each packet will reduce the system throughput even further. > It might prevent other >attacks that have not been envisioned. For a performance-critical design this is a non-argument. We could apply an FFT, and it may prevent certain attacks, but we won't. > >> Rotating the output in a key-dependent way is dangerous. You expose the >> rotation constants to discovery using a differential attack. > >If the rotation constants are derived from the MIC key using a strong hash >(e.g. SHA1) there is little risk of recovering key bits. Since this only >needs to be done when the MIC key changes, the computation time should be >afordable. But you'd need to implement SHA1 in software. I don't know whether there is enough code and memory space on each of the fielded chip sets. Do you? And do we have a cost estimate for implementing SHA1 on all fielded chip sets? And how does that cost estimate compare to security improvement? Is this worthwhile? 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. [...] >Another cheap varient would be to derive the rotation constants from the >hash of the last two MIC keys. This eliminates even this minute risk. No, that doesn't work. It would mean that doing a re-key protocol does not ensure that the keys on both sides agree. 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. >> Additional integrety checks would require extra cycles, which we could also >> have spent on a more secure Michael version. >> > >I wasn't suggesting they be done by 802.11, but by higher layers. If you are suggesting to run IPsec over 802.11, I'm all for it. That is the configuration that I would suggest. IPsec over 802.11, with the best 802.11 crypto switched on of course. But the higher layers are outside the scope of our discussion. We are providing 802.11 security and can't count on the higher layers. Cheers! Niels ============================================================== Niels Ferguson, [EMAIL PROTECTED], phone: +31 20 463 0977 PGP: 3EC2 3304 9B6E 27D9 72E7 E545 C1E0 5D7E --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
