[throwasehasdwi]

You can't brute force a nonce offline when you don't know if you answer is right unless you ask the AP. Different protocols than sending hashes where you can tell if your hash is correct just by looking at it.

You are right that the AP couldn't block you without blocking everyone, but since you need to check your answer with the AP for each guess your attack becomes extremely visible. I guess you could still DDOS the AP by sending auth requests faster than it allows but that doesn't hurt the channel any more than barrage jamming which is un-blockable.

[xori]

But you can capture the first encrypted packet from the router, and you know what the protocol is to test if your decoded version is correct. I still don't see how this helps.

[zeta0134]

This is a reasonable guess at how encryption works, but it's also flawed. The key you need to crack on a Wireless Router isn't the key that's used for actual encryption of data, but rather the key used to set up that encryption in the first place.

Basically, your keys are used to handshake with the access point, and then exchange a new set of temporary keys for the duration of your connection. These temporary keys (which are exchanged during the handshake, and encrypted by something which involves your original keys) are then used to encrypt user data.

Because the data are encrypted with new keys for each connection, and those keys aren't based on the original keys in any way, knowing the plain text version of the data you're trying to decrypt doesn't help. You might be able to recover the temporary key, but you can't use this by itself to join the router, and the key is thrown away when that user makes a new connection. (These keys are also usually quite large, random, and very resistant to brute force methods anyway.)

HTTPS works similarly, and it needs to, because many (many!) websites start with the plain text "<html" which would make it trivial to brute force the keys offline otherwise.

[amenghra]

The difference between an access point and HTTPS on a web server is that the access point doesn't have an identity to tie the key exchange. You can sprinkle DH here and there to incrementally improve things but it's not going to be bullet proof against active man-in-the-middle attacks.

With things like Lets Encrypt, having each access point own a short lived certificate becomes possible and you can then bootstrap a secure key exchange.

PS: I have no idea which direction WPA3 is going. They might be doing something without certs but a TOFU trust model instead. Either ways, it is possible to design something better than WPA/WPA2 but don't think it's trivial because the constraints aren't the same as existing secure protocols.

[sasebot]

>>>The difference between an access point and HTTPS on a web server is that the access point doesn't have an identity to tie the key exchange. You can sprinkle DH here and there to incrementally improve things but it's not going to be bullet proof against active man-in-the-middle attacks.

??? Isnt the MAC address an identity for the AP ?

I always had a doubt about HTTPS . Say Im connecting through a proxy server to a website. The exchange of keys for HTTPS connection happens through this proxy server, means it can capture those and decrypt the connection whenever it wants , right ? Thanks for your reply.

[icebraining]

??? Isnt the MAC address an identity for the AP ?

No, just an address. To be an identity, there must be some way for the AP to demonstrate that it is the right owner of that MAC, otherwise any router can simply copy the MAC.

HTTPS sites do this by getting a CA to vouch for them (in the form of a digitally signed certificate). Tor sites do this by having their address being a representation of their public key, and proving they have the corresponding private key.

I always had a doubt about HTTPS . Say Im connecting through a proxy server to a website. The exchange of keys for HTTPS connection happens through this proxy server, means it can capture those and decrypt the connection whenever it wants , right ? Thanks for your reply.

No, thanks to Diffie-Hellman[1], you can exchange keys with a remote server over a non-secure channel in a way that anyone listening can't figure out the key.

Of course, this happens after the server has proven it is who it says it is, by using one of the methods above. Otherwise, the proxy could pretend to be the server, and exchange keys itself with you.

[1] https://security.stackexchange.com/questions/45963/diffie-he...

[slackingoff2017]

You can have bulletproof protection against MITM as long as you have a shared secret so it's possible with wifi. The other answers in this chain about PAKE have details.

[slackingoff2017]

It is correct that HTTPS and other protocols generate temporary keys for each connection but there's another much older reason why this is done, particularly for TLS.

Asymmetric encryption algorithms are, in general, orders of magnitude slower at encryption than AES. With these protocols the initial secure connection is done using asymmetric cryptography. It makes sense to use the established secure channel to exchange another set of keys and switch over to AES or another symmetric algorithm immediately.

Nowadays the two ends negotiate a key exchange to allow things like perfect forward secrecy as well, so this is becoming a historical footnote to an extent.

[throwasehasdwi]

I'm not a crypto expert and I'm sure even if I was it would be difficult to explain. Wiki page on SRP has a good description though:

Like all PAKE protocols, an eavesdropper or man in the middle cannot obtain enough information to be able to brute force guess a password without further interactions with the parties for each guess.

In layman's terms, given two parties who both know a password, SRP (or any other PAKE protocol) is a way for one party (the "client" or "user") to demonstrate to another party (the "server") that they know the password, without sending the password itself, nor any other information from which the password can be broken. Further, it is not possible to conduct an offline brute force search for the password.

https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

[xori]

To clarify, I agree that the individual connection key is safe from brute force. But I feel like the initial shared key is vulnerable. I doubt you'd get MITM on your connection, but you can still get a bad actor on your network.

I feel like the initial key exchange should be done with something most resource intensive than elliptic curves.

[hueving]

Knowing the plaintext version of a packet does not allow you to get the key. That's called a known plaintext attack and AES is resistant to it.