Re: 802.11 Wired Equivalent Privacy (WEP) attacks
WF1 In WF1 the 802.11 WEP keys would be changed many times each hour, say every 10 minutes. A parameter, P , determines how many time per hour the key is to be changed, where P must divide 3600 evenly. The WEP keys are derived from a master key, M, by taking the low order N bits (N = 40, 104, whatever) of the SHA1 hash of the master key with the date and time (UTC) of the key change appended. WEPkey = Bits[0-N](SHA1(M | mmddhhmmss)) (snip) Clearly good synchronization of the time-of-day clock on each node is essential in WF1, but protocols already exist that can do this over a network. Small synchronization discrepancies can be handled by the 802 retry mechanism and should look very much like a short RF outage. i see chicken and egg loop here - for instance, if I've got a laptop with 802.11 card only, I need to use the 802.11 network to synchronize clock. i'm not sure if WF1 is workable (if you have other secure channel for synchronizing clock, you are okay - but then why bother using 802.11?). itojun
Re: 802.11 Wired Equivalent Privacy (WEP) attacks
At 5:55 AM +0900 2/10/2001, [EMAIL PROTECTED] wrote: WF1 In WF1 the 802.11 WEP keys would be changed many times each hour, say every 10 minutes. A parameter, P , determines how many time per hour the key is to be changed, where P must divide 3600 evenly. The WEP keys are derived from a master key, M, by taking the low order N bits (N = 40, 104, whatever) of the SHA1 hash of the master key with the date and time (UTC) of the key change appended. WEPkey = Bits[0-N](SHA1(M | mmddhhmmss)) (snip) Clearly good synchronization of the time-of-day clock on each node is essential in WF1, but protocols already exist that can do this over a network. Small synchronization discrepancies can be handled by the 802 retry mechanism and should look very much like a short RF outage. i see chicken and egg loop here - for instance, if I've got a laptop with 802.11 card only, I need to use the 802.11 network to synchronize clock. i'm not sure if WF1 is workable (if you have other secure channel for synchronizing clock, you are okay - but then why bother using 802.11?). That is one of the reasons I suggested a key change interval of every 10 minutes. Most PCs internal clocks will keep time to within a few seconds from day to day, so re-synchronization should not be a problem. If necessary the PC's time can be manually set well enough using any number of time sources: Most phone companies in the US have a number you can call. "News" radio stations announce the time frequently. Many cell phones have clocks. GPS receivers give accurate time. For about $60 you can buy a clock that synchronizes itself to WWVB. 802.11 has a short range, so there are likely other PCs nearby that you can get the time from. I don't know how tolerant actual 802.11 systems are to a delayed key change (experiments are welcome), but if a user sets their PC time in the middle of a ten minute interval, there will be no delay at all. Actually there is a highly accurate time synchronism mechanism built into 802.11. The transceivers must be sync'd way before they get to worry about encryption. But I don't know if that time value is accessible by the client computer. If so, more frequent key changes should be workable. Arnold Reinhold
Re: 802.11 Wired Equivalent Privacy (WEP) attacks
At 12:05 PM -0500 on 2/8/01, Arnold G. Reinhold wrote: Thus there is a need for a short term remedy that can work with the existing standard. Not to pull your leg (too hard), or anything, but, we were told, at mac-crypto, that it's called "super-encryption". ;-) IPSec anyone? Cheers, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
Re: 802.11 Wired Equivalent Privacy (WEP) attacks
Arnold G. Reinhold wrote: Thus there is a need for a short term remedy that can work with the existing standard. Maybe the easiest short term remedy that does not require any changes to hardware is the following: * Put the wireless network outside your firewall (or place a firewall between your wireless network and your internal, security-sensitive network), and * Use a VPN with strong end-to-end cryptographic authentication and encryption (e.g., IPSEC or equivalent) In short, don't trust the wireless devices to provide security -- treat the wireless cards as a way of getting insecure access, and then use an independent security mechanism.
New stuff with Envelope Mail
I've done a bunch more work on Envelope Mail, as always, the latest info is at - http://gawth.com/bram/envelope_mail/ New is actual code, complete with test code. Plans are next to write a patch for BoboMail implementing the dummy version of the crypto API. I could use immediate help on the following things - A logo - I'm incapable of graphic design A non-dummy version of the crypto API - the dummy one makes it excruciatingly clear how the real one should work and gives a strong indication of how it might be implemented. I'd make the 'real' one myself, but, you know, you're not supposed to do that, and I'm trying to play nice, despite the crypto community being remarkably unhelpful in this regard. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes
