Nabil90
Status: n/a
Joined: Sun, 11 Jun 2017
Posts: 85
Team:
Reputation: 50
Offline
|
Thu, 05 Jul 2018 @ 19:36:30
I can sort of figure out how using Diffie-Hellman in SAE protects the authentication handshake from a third party observing the transaction, or any capture of it, because the third party can never work out the shared key negotiated by Diffie-Hellman. But what about an impersonation attack where one side knows the passphrase and the attacking side does not? Surely then the attacking side can still work out the shared key by participating in the Diffie-Hellman exchange? If the attacker knows the shared key for one transaction, doesn't that give some way to attack the passphrase?
|
mkerr
Status: Banned
Joined: Sun, 03 Sep 2017
Posts: 377
Team:
Reputation: 317
Offline
|
Thu, 05 Jul 2018 @ 20:38:32
WARNING! User is BANNED and maybe a SCAMMER. The short answer is that you can only make one guess and if you guess wrong, nothing in that transaction gives you any information that will help you to find the correct passphrase The passphrase is mapped onto a Password Element (PWE). This is done in a deterministic way, so both sides will end up using the same PWE if they know the same passphrase. In an Elliptic Curve Field, the PWE will be a point on the Elliptic Curve This PWE is used as the base of the Diffie-Hellman calculations on both sides, so if the two ends use a different PWE (because one side is guessing the passphrase), then the Diffie-Hellman secret derived on both sides will be different and nothing from that point on will match and the authentication will fail In addition, the Diffie-Hellman shared secret is based on both the PWE and two private random numbers from each side. That makes it impossible to figure out the expected result for a different PWE without running another complete transaction from scratch There is nothing you can do with GPUs or whatever to discover anything about the passphrase In principle you could constantly retry with different passphrases, but that approach is going to be impossibly slow for passphrases that you could crunch through easily with WPA2 using GPUs Plus it is trivial in WPA3 to add rate limiting or lockouts on failed authentications which makes it even more impossible to guess
|
Nabil90
Status: n/a
Joined: Sun, 11 Jun 2017
Posts: 85
Team:
Reputation: 50
Offline
|
Thu, 05 Jul 2018 @ 22:08:37
Sounds like they thought of everything this time around?
|
mkerr
Status: Banned
Joined: Sun, 03 Sep 2017
Posts: 377
Team:
Reputation: 317
Offline
|
Fri, 06 Jul 2018 @ 01:00:16
WARNING! User is BANNED and maybe a SCAMMER. Nabil90 said: Sounds like they thought of everything this time around? The theory of Password Authenticated Key Exchange used in SAE was known well before WPA2 was released, so it has only taken about 15 years for the Wifi-Alliance to react to the threat of offline cracking, plus maybe about another 5-10 years of migration away from WPA2 still ahead?
|
soxrok2212
Status: Cracker
Joined: Sat, 24 Oct 2015
Posts: 451
Team:
Reputation: 421
Offline
|
Fri, 06 Jul 2018 @ 03:57:13
Thanks for the information maker. I have two questions: 1. Granted a vendor chooses a static private key and that private key is found, could one use this to intercept a valid exchange? Some manufacturers did this in WPS. 2. A lot of this stuff is over my head, do you have any other resources that you could share to help me understand everything that’s going on a bit better?
BTC: 1B4ZAbWYQ399p6QJm3VLbywiCWVSBAXYJ1 NVIDIA 1x GTX 1080 Founder’s Edition 1x GTX 980 Reference Design
|
mkerr
Status: Banned
Joined: Sun, 03 Sep 2017
Posts: 377
Team:
Reputation: 317
Offline
|
Fri, 06 Jul 2018 @ 06:51:18
WARNING! User is BANNED and maybe a SCAMMER. soxrok2212 said: 1. Granted a vendor chooses a static private key and that private key is found, could one use this to intercept a valid exchange? Some manufacturers did this in WPS.
If a vendor made the mistake of using a fixed and known private value, that would certainly break all security guarantees for SAE. Passive attack by a third party would remain difficult, if the other peer was still correctly using an unknown private key, but an impersonation attack against the flawed vendor would effectively allow a dictionary search for the passphrase This is because if the private key is fixed and known, the only remaing variable is the PWE being used by the vendor, which is deterministically derived from the passphrase. Many passwords could then tried offline to find one consistent with how the protocol evolved during one failed authentication soxrok2212 said: 2. A lot of this stuff is over my head, do you have any other resources that you could share to help me understand everything that’s going on a bit better?
Section 11.3 of 802.11(2012) is probably the most detailed reference of the Dragonfly protocol, but like most of these specs, it often feels like you have to read every line 100 times over before you even begin to understand what they are saying RFC6617 might be slightly more readable, even though it relates to IKE and some of the terminology is a little different
|
st4rm4n
Status: n/a
Joined: Fri, 21 Sep 2018
Posts: 12
Team:
Reputation: 0
Offline
|
Mon, 01 Oct 2018 @ 19:47:14
Anyone else know anything more about WPA3?
|
Nabil90
Status: n/a
Joined: Sun, 11 Jun 2017
Posts: 85
Team:
Reputation: 50
Offline
|
Sat, 10 Nov 2018 @ 10:06:35
st4rm4n said: Anyone else know anything more about WPA3? Not looking like anyone does, but there is still quite a lot of good information in this thread if you follow the references The Wi-Fi Alliance page is now showing 100 router implementations have already achieved WPA3 certification
|