The idea here (I know, I was there when we voted it into the standard) is that the PBKDF2 is computationally significant.
Thus when you perform your offline dictionary attack, for each lookup in the dictionary, you must perform 4096 HMAC_SHA1s and this might take some time if you are looking up a large number of dictionary entries.
The basic conflict is the wide disparity between the power of processors in low end 802.11 transceivers and high end computers. The time to compute the 4096 HMAC-SHA1s is significant on say a slow ARM7TDMI and the 4096 value is a compromise to limit the delay in computing this. This delay affects the time from pressing return on the keyboard, to the time the PTK can be known and communications can begin.
However the attacker can apply his cluster of 3GHz PCs, or his FPGA HMAC_SHA1 parallel processor, or his supercomputer array, and make the speed of dictionary lookups relatively insignificant compared against the strength of the passwords being used.
The wise people asked for a much higher number than 4096. Some implementation types beat it down to 4096, and here we are..
>It's far from perfect, but is not nearly as bad as people make it out to be.
Oh yes it is. WEP+ is not a standard. Different vendors have different means of avoiding (or not) weak keys.
Problem 1: Weak key avoidance just makes the IV space get exhausted quicker.
Problem 2: There are likely to be new classes of weak keys discovered that invalidate the weak key skipping mechanisms and further shink the IV space.
Problem 3: If you have no weak keys, then IV space exhaustion gets you in the end.
Problem 4: To solve IV space exhaustion within the current WEP structure, you need rapid rekeying. There is no rapid rekeying spec. 802.1X is used be vendors in the wild, but only in proprietary ways, since as a standard it doesn't work over a non secured channel like 802.11.
Problem 5: 802.1X has some fundamental layer violation problems with networks that don't have an ethertype (like 802.11). Ethernet is fine. It has an ethertype.
I thought security included confidentiality, authentication, integrity and non-repudiation. 802.11 currently has none of these in any effective form. The future 802.11i draft is not likely to give you non-repudiation, sorry.
They [e,f,g,h,i] will all get rolled up into one big honking spec called 802.11-200[3|4|5|6] or whenever. The mismatches between the text of the individual specs get cleaned up at this point. That will be the spec.
The last big honking rolled up spec was 1999. That incorporated 802.11b for 11mbps at 2.4Ghz
The approved individual drafts will get approved by the working group, then approved at sponsor ballot and then they will sit around waiting to be incorporated into a unified spec. The approved drafts that have been through sponsor ballot are OK to implement to, in that they will not change.
TGi deals with security. So that would be 802.11i. In the interim there is WPA. WPA is not an 802.11 thing, it is a WECA spec. It is poor mans security, better than WEP but worse than 802.11i.
802.11g is not a standard. The standard is not yet written. It is in a draft form. At the most recent 802.11 meeting it was in comment resolution and the text was being changed in significant ways.
Claiming compliance to 802.11g at this date is to lie.
PBCC or OFDM phy based equipment at 2.4Ghz is not at this time 802.11 anything. It is proprietary. Buy it and you are buying proprietary, non interoperal stuff. Kids, just say 'no'.
Tivos are not very happy with the notion of being switched off.
I would prefer a thin client system (AV devices attached to ethernet, with built in MPEG decoder in rooms around the house and a nice server in the closet hosting the music, programs and Tivo style capture. No fans or hard disks in the rooms, centralized content distribution and plenty of scope to annoy the copyright laywers.
>For the love of Pete, do you really have to watch that much TV? Get a fuckin life.
Perhaps you would like to tell that to my 18 month old daughter who shuts up, sits still and watches the Teletubbies for half an hour in the morning, via the Tivo in the bedroom, enabling me to brush my teeth. Or the teenagers who fill the Tivo in the family room with MTV junk. Completely worth it. Perhaps you should 'Get a fuckin' clue.
802.11 Unicast transmissions could be beam steered to improve range.
802.11 AP and IBSS Broadcast transmissions need to be heared by everyone. Thus they can't be beam steered.
So you might be able to communicate via an AP from further away, but you'll never get past the beacon scanning, probe, probe response stuff to get authenticated and associated in the first place.
WiFi Alliance docs are available to WiFi alliance members.
802.11i docs are available to 802.11 members.
To get the 802.11 docs you must attend an 802.11 meeting and pay the up front money ($250-$400 depending on the phase of the moon. I believe WiFi alliance membership costs money.
So a stay-at-home hacker is going to have a hard time implementing WPA/TKIP for Linux unless someone is naughty and slips them copies of the specs.
This article doesn't really give the whole story..
WPA is a renaming of SSN. This is based around a scheme called TKIP (temporal key integrity protocol).
TKIP attempts to wrap WEP in mechanisms to address all the currently known attacks against WEP. This is with the express intention of allowing it to be provided as a software upgrade to existing hardware.
TKIP does not attempt to be super secure. It does various bad things from a cryptographic standpoint. It is just that exploits haven't been discovered yet.
The mechanisms of TKIP are: 1) Key and IV mixing. The IV and the key are cryptographically mixed to avoid weak key attacks. 2) Longer IV. The IV is 48 bits, not 24. Preventing Key/IV pair reuse. 3) An MSDU level MAC (Message Authentication Code) called a MIC (to avoid overloading the term MAC). This gives proper message authentication and replay protection. The WEP ICV fails badly in this respect. 4) An 802.1x derived protocol for mutual STA-AP and AP-STA authentication and key distribution.
Things to keep in mind are.. 1) TKIP fails in its goal to be backwards compatible with some existing hardware. It will not work on some manufacturers equipment, since they cannot insert the mixed key into the system at a point to replace the RC4 WEP seed. 2) This is a stopgap to hold out until real security can be provided via 802.11i, using some mode of AES. 3) It is not using vanilla 802.1x. The 802.1x spec has been rewritten in places to provide for the needs of 802.11. So it is not enough to just read 802.1x. You also need to be aware of the as yet unpublished changes in 802.1aa and 802.11i.
This is Dilution of Distributed Compute Power!
on
ECCp-109 Solved
·
· Score: 1, Interesting
The number of simultaneous distributed attempts against hard compute problems should be limited to 1.
Having all these different crypto challenges, protien folding challenges, SETI searches etc, just dilutes the pool of available computers for each task.
This seems easy to circumnvent
on
Wireless Camouflage?
·
· Score: 2, Interesting
The messaging of WEP security associations within the 802.11 mac spec is performed in the clear by passing challenge texts and responses around.
So just compile a list of all the APs you see and listen out for a good security association. From this you can devine the real AP.
With the proposed enhanced security mechanisms (TKIP & AES) the encryption similarly is not turned on until a security association (based on 802.1x) is completed. You can see this happen on the air and you can see which AP is being communicated with.
For this to work well you might need to also fake lots of good security associations to all the fake APs that are beaconing.
I see this is a poor mechanism. It is security through obscurity. It can be circumvented and the beacons suck away bandwith.
I have been in ASIC engineering for the past 11 years. I have seen things moving towards Linux as the underlying OS for the past 2-3 years.
It appears to go hand in hand with the fastest uniprocessor platforms looking fast compared to the fastest uniprocessor suns.
The software we use is very expensive and generally compute intensive. So it pays to run it on the fastest hardware and it pays to buy the fastest hardware when it is the cheapest. The only exceptions are tools that require 64 bit addresses to permit enough memory to be installed (E.G. IC layout). Sun still wins there.
When PCs are both the fastest and cheapest and Unix is the operating system of choice for engineers and Linux is both free and good, the preference is obvious.
We pretty much will not buy software that does not run on Linux and the ASIC tool vendors know it.
The same market forces seem to apply in here mechanical engineering.
High resolution with normal refresh rates requires high bandwidth. These tiny little devices are going to look pretty silly with four BNC connectors and and IEC plug hanging out the back.
>Why not use a 128-bit or 196-bit cryptographic hash (MD5 or SHA)? You better be prepared to waste a lot of time if you want to create a file with a particular hash value.
Well you might. I was merely recounting my experience with idiots trying to scan for illegally copied software. I did not imply anyone referenced in the original post was an idiot. It seems that other people have been doing that.
I recollect that while working at a previous employer, they sent around some software that compared the CRC of files on the hard disk against a database of commercial software CRCs and then flagged the matches.
This was rendered completely pointless since 1) The CRC they used was 16 bit. I worked for a large CAD company and every had a *lot* of files laying around as a result. The number of false positives drowned out the real positives.
2) It is a trivial excercise for anyone to create files with a predetermined CRC, so digital decoys can easily be scattered around the internet
Exposure to bacteria is normal. We did not evolve with bleach and lavatories. Our bodies expect to encounter bacteria and to some expect we have to to keep out immune systems primed.
Why get paranoid about bacteria that naturally crawls over pretty much everything in our environment. Have you got ill off your keyboard? No, I didn't think so.
Slashdot Mirror
The idea here (I know, I was there when we voted it into the standard) is that the PBKDF2 is computationally significant.
Thus when you perform your offline dictionary attack, for each lookup in the dictionary, you must perform 4096 HMAC_SHA1s and this might take some time if you are looking up a large number of dictionary entries.
The basic conflict is the wide disparity between the power of processors in low end 802.11 transceivers and high end computers. The time to compute the 4096 HMAC-SHA1s is significant on say a slow ARM7TDMI and the 4096 value is a compromise to limit the delay in computing this. This delay affects the time from pressing return on the keyboard, to the time the PTK can be known and communications can begin.
However the attacker can apply his cluster of 3GHz PCs, or his FPGA HMAC_SHA1 parallel processor, or his supercomputer array, and make the speed of dictionary lookups relatively insignificant compared against the strength of the passwords being used.
The wise people asked for a much higher number than 4096. Some implementation types beat it down to 4096, and here we are..
I've used this book for years as my first point of reference when I have 'quantitive information' to display.
Every engineer should have one to hand to keep themselves safe from the brain warping effects of powerpoint.
So how long until ITV (The TV channel) in the UK decides to let their lawyers loose?
> Well, thanks, but that doesn't quite answer the question. If I buy an 802.11g network, do I still have to worry about all this stuff?
Yes.
>It's far from perfect, but is not nearly as bad as people make it out to be.
Oh yes it is.
WEP+ is not a standard. Different vendors have different means of avoiding (or not) weak keys.
Problem 1: Weak key avoidance just makes the IV space get exhausted quicker.
Problem 2: There are likely to be new classes of weak keys discovered that invalidate the weak key skipping mechanisms and further shink the IV space.
Problem 3: If you have no weak keys, then IV space exhaustion gets you in the end.
Problem 4: To solve IV space exhaustion within the current WEP structure, you need rapid rekeying. There is no rapid rekeying spec. 802.1X is used be vendors in the wild, but only in proprietary ways, since as a standard it doesn't work over a non secured channel like 802.11.
Problem 5: 802.1X has some fundamental layer violation problems with networks that don't have an ethertype (like 802.11). Ethernet is fine. It has an ethertype.
I thought security included confidentiality, authentication, integrity and non-repudiation. 802.11 currently has none of these in any effective form. The future 802.11i draft is not likely to give you non-repudiation, sorry.
>This is also getting so much press because since it is 100% backwards compatible with 802.11b
Except for 802.11g BSSes with short slot time screwing up 802.11b overlapping BSSes.
They [e,f,g,h,i] will all get rolled up into one big honking spec called 802.11-200[3|4|5|6] or whenever. The mismatches between the text of the individual specs get cleaned up at this point. That will be the spec.
The last big honking rolled up spec was 1999. That incorporated 802.11b for 11mbps at 2.4Ghz
The approved individual drafts will get approved by the working group, then approved at sponsor ballot and then they will sit around waiting to be incorporated into a unified spec. The approved drafts that have been through sponsor ballot are OK to implement to, in that they will not change.
TGi deals with security. So that would be 802.11i.
In the interim there is WPA. WPA is not an 802.11 thing, it is a WECA spec. It is poor mans security, better than WEP but worse than 802.11i.
802.11g is not a standard. The standard is not yet written. It is in a draft form. At the most recent 802.11 meeting it was in comment resolution and the text was being changed in significant ways.
Claiming compliance to 802.11g at this date is to lie.
PBCC or OFDM phy based equipment at 2.4Ghz is not at this time 802.11 anything. It is proprietary. Buy it and you are buying proprietary, non interoperal stuff. Kids, just say 'no'.
Tivos are not very happy with the notion of being switched off.
I would prefer a thin client system (AV devices attached to ethernet, with built in MPEG decoder in rooms around the house and a nice server in the closet hosting the music, programs and Tivo style capture. No fans or hard disks in the rooms, centralized content distribution and plenty of scope to annoy the copyright laywers.
>For the love of Pete, do you really have to watch that much TV? Get a fuckin life.
Perhaps you would like to tell that to my 18 month old daughter who shuts up, sits still and watches the Teletubbies for half an hour in the morning, via the Tivo in the bedroom, enabling me to brush my teeth. Or the teenagers who fill the Tivo in the family room with MTV junk. Completely worth it. Perhaps you should 'Get a fuckin' clue.
Comparing VCR noise against PVR noise is not an apples to apples comparison.
The VCR makes its noise most commonly when operating, with either the TV on or the user away.
The PVR makes its noise most of the time, regardless of the presence of the user.
A Tivo is pretty annoying at night in a quiet bedroom. The low levels of noise become much much more audible and annoying in that environment.
802.11 Unicast transmissions could be beam steered to improve range.
802.11 AP and IBSS Broadcast transmissions need to be heared by everyone. Thus they can't be beam steered.
So you might be able to communicate via an AP from further away, but you'll never get past the beacon scanning, probe, probe response stuff to get authenticated and associated in the first place.
WiFi Alliance docs are available to WiFi alliance members.
802.11i docs are available to 802.11 members.
To get the 802.11 docs you must attend an 802.11 meeting and pay the up front money ($250-$400 depending on the phase of the moon. I believe WiFi alliance membership costs money.
So a stay-at-home hacker is going to have a hard time implementing WPA/TKIP for Linux unless someone is naughty and slips them copies of the specs.
Weak key avoidance involves skipping over weak IVs.
This shortens the time before the IV space has been exhausted and security is compromised through Key/IV pair reuse.
So it is six of one, half a dozen of the other.
This article doesn't really give the whole story..
WPA is a renaming of SSN. This is based around a scheme called TKIP (temporal key integrity protocol).
TKIP attempts to wrap WEP in mechanisms to address all the currently known attacks against WEP. This is with the express intention of allowing it to be provided as a software upgrade to existing hardware.
TKIP does not attempt to be super secure. It does various bad things from a cryptographic standpoint. It is just that exploits haven't been discovered yet.
The mechanisms of TKIP are:
1) Key and IV mixing. The IV and the key are cryptographically mixed to avoid weak key attacks.
2) Longer IV. The IV is 48 bits, not 24. Preventing Key/IV pair reuse.
3) An MSDU level MAC (Message Authentication Code) called a MIC (to avoid overloading the term MAC). This gives proper message authentication and replay protection. The WEP ICV fails badly in this respect.
4) An 802.1x derived protocol for mutual STA-AP and AP-STA authentication and key distribution.
Things to keep in mind are..
1) TKIP fails in its goal to be backwards compatible with some existing hardware. It will not work on some manufacturers equipment, since they cannot insert the mixed key into the system at a point to replace the RC4 WEP seed.
2) This is a stopgap to hold out until real security can be provided via 802.11i, using some mode of AES.
3) It is not using vanilla 802.1x. The 802.1x spec has been rewritten in places to provide for the needs of 802.11. So it is not enough to just read 802.1x. You also need to be aware of the as yet unpublished changes in 802.1aa and 802.11i.
The number of simultaneous distributed attempts against hard compute problems should be limited to 1.
Having all these different crypto challenges, protien folding challenges, SETI searches etc, just dilutes the pool of available computers for each task.
The messaging of WEP security associations within the 802.11 mac spec is performed in the clear by passing challenge texts and responses around.
So just compile a list of all the APs you see and listen out for a good security association. From this you can devine the real AP.
With the proposed enhanced security mechanisms (TKIP & AES) the encryption similarly is not turned on until a security association (based on 802.1x) is completed. You can see this happen on the air and you can see which AP is being communicated with.
For this to work well you might need to also fake lots of good security associations to all the fake APs that are beaconing.
I see this is a poor mechanism. It is security through obscurity. It can be circumvented and the beacons suck away bandwith.
TKIP is the way to go.
US digital TV receivers are required to use the frankly stupid ATSC format, while the rest ofthe world gets to use the rather sensible OFDM scheme.
So people in the US get a piece of crap (worse spectrum usage, no doppler tolerance -> no mobile apps).
Why whould people buy it?
I have been in ASIC engineering for the past 11 years. I have seen things moving towards Linux as the underlying OS for the past 2-3 years.
It appears to go hand in hand with the fastest uniprocessor platforms looking fast compared to the fastest uniprocessor suns.
The software we use is very expensive and generally compute intensive. So it pays to run it on the fastest hardware and it pays to buy the fastest hardware when it is the cheapest. The only exceptions are tools that require 64 bit addresses to permit enough memory to be installed (E.G. IC layout). Sun still wins there.
When PCs are both the fastest and cheapest and Unix is the operating system of choice for engineers and Linux is both free and good, the preference is obvious.
We pretty much will not buy software that does not run on Linux and the ASIC tool vendors know it.
The same market forces seem to apply in here mechanical engineering.
High resolution with normal refresh rates requires high bandwidth. These tiny little devices are going to look pretty silly with four BNC connectors and and IEC plug hanging out the back.
>Why not use a 128-bit or 196-bit cryptographic hash (MD5 or SHA)? You better be prepared to waste a lot of time if you want to create a file with a particular hash value.
Well you might. I was merely recounting my experience with idiots trying to scan for illegally copied software. I did not imply anyone referenced in the original post was an idiot. It seems that other people have been doing that.
I recollect that while working at a previous employer, they sent around some software that compared the CRC of files on the hard disk against a database of commercial software CRCs and then flagged the matches.
This was rendered completely pointless since
1) The CRC they used was 16 bit. I worked for a large CAD company and every had a *lot* of files laying around as a result. The number of false positives drowned out the real positives.
2) It is a trivial excercise for anyone to create files with a predetermined CRC, so digital decoys can easily be scattered around the internet
Exposure to bacteria is normal. We did not evolve with bleach and lavatories. Our bodies expect to encounter bacteria and to some expect we have to to keep out immune systems primed.
Why get paranoid about bacteria that naturally crawls over pretty much everything in our environment. Have you got ill off your keyboard? No, I didn't think so.