Slashdot Mirror
WEP Gets A Bit Stronger
gmr2048 writes: "CNN is reporting that RSA has helped develop "Fast Packet Keying" to strengthen WEP security. More info can be found at the RSA page. Damn, and I'm still working on my Pringles can antenna."
← Back to Stories (view on slashdot.org)
I see two main reasons why packet-level encryption is worthwhile (assuming it isn't totally broken, of course):
Personally, I'm happy to have working packet-level encryption because that adds one more layer. SSH over IPSec over WEP, anyone?
Fast Packet Keying," a new technology based on the RC4® algorithm, is designed to help organizations securely fix the WEP encryption standard. This new WEP solution, developed by RSA Security, Hifn and other members of the 802.11 committee, is designed to generate a unique RC4 key for each data packet sent over the wireless LAN.
The fix to WEP was developed by a working group in which RSA was far from being the sole contributor. It is a bit off for RSA to try to claim the glory for the fix when a significant part of the WEP problem is due to a weakness in the keying scheme of RC4.
The presentation lists as 'key contributors' Jessie Walker of Intel, Bob Beach and Clint Chaplin from Symbol, Ron Brockman of Intersil Nancy Cam-Winget of Atheros Greg Chesson, Atheros Niels Ferguson, MacFergus BV Marty Lefkowitz, TI Bob O'Hara, Blackstorm Networks Dorothy Stanley, Agere Doug Smith, Cisco Albert Young, 3COM
So when RSA wants to get votes it has a dozen 'key contributors'. But when they want to take the credit there are two.
The original algorithm was botched, in part it is claimed (by an informed source) because the original IEEE working group left the crypto to an NSA advisor. Failing to understand the specific weakness of using a stream cipher in general and the specific weaknesses of the RC4 key scheme are the major reasons for the failure of the WEP design.
One could rightly blame the original working group for failing to read up on the litterature and avoid the known flaws of RC4, only RC4 was until recently a proprietary and secret algorithm of RSA. The key scheme flaws were only publicised after RC4 was reverse engineered without RSA approval, and resulted in considerable protest by RSA.
This type of publicity grab is not good for open standards development. It encourages people to release their proposals to the press rather than to the working group.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
RC4 has a specific design flaw whereby the cipherstream for k has similarities to the cipher stream for k+1. These allow an attacker with cipher text for k and k+1 to recover the plaintext of the messages and the key.
One fix is to throw away the first 256 bytes or so of the cipherstream. Another solution is to make the probability of a collision very small which is what the fast keying scheme is doing.
The main constraint on the solution is that it has to be deployable on cards that have already been manufactured and those are not particularly powerful CPU wise.
The Berkely attack is certainly a concern, 24 bit encryption is not acceptably secure. But that is not the weakness being exploited by AirSnort. There are a bunch of mixing functions defined in the presentation I have seen but there is insufficient info to know if it does indeed do the right thing.
Again, I am somewhat anoyed when cryptographic protocols are puffed in the press prematurely. I am not a member of the 802.11b group, however I will be reviewing their work product when they announce it is ready. I am not aware that this is currently the case. I would like something more than a powerpoint presentation to evaluate the protocol by.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
portions of encryption technologies are already implemented in the Intel Pro100 network cards.
i dont know how hard it would be to offload portions of IPSec to the network card. i know that freebsd can do checksum offloading if the network card supports it.
RC4 is broken? Oh really?
I know the first 40 bytes have noticable correlations to the key. That's avoided by skipping the first 256 bytes. I know that if you see 2^^31 bytes of an RC4 stream you can distinguish it from random noise. That's not an interesting flaw at all, unless you're generating 2gig of data and you don't want anyone to know which encryption protocol you're using. Did you mean something more by saying "RC4 is broken"?
IPsec for IPv6 (and I assume IPv4) is pretty flexible and can be used on UDP (DNS, DHCP), and I *think* ICMP
Well, yes and no. DNS, for example, works fine if you have LAN clients and your single LAN DNS server, but you won't be likely to set up IPSec SAs with many external servers.
DHCP, no - how can you set up an SA when one of the endpoints has no IP address? (Not that DHCP is all that much worth protecting, but...)
ICMP, same as DNS - how many remote systems are you going to have, or be able to negotiate, SAs with?
Now, once IPv6 comes in, and IPSec becomes truly opportunistic, maybe - but in IPv4, it isn't really useful for "casual" encryption.
There's another reason why packet-level is nice; tunneling doesn't survive putting your laptop to sleep for any length of time. We use an SSH-based VPN for work, and it works swell, but it means I tend to lug my laptop around the apartment with the clamshell open :(.