Is there a way to secure an wireless connection against a decryption attack where the PSK is known (E.G. Airdecap-NG)? Is it possible to configure Forward Secrecy on 802.11 Wireless Connections?

2 Answers 2


Forward secrecy is achieved by using ephemeral keys. That's the point of it: you get forward secrecy by using encryption keys which cannot be stolen afterwards because they were never stored on a physical medium; they were stored in RAM only, and have been destroyed after usage. They're gone.

The fine details: this definition extends to whatever can be rebuilt from stored and exchanged values. For instance, in WPA2-PSK, there is an initial shared secret (the password), which is stored, and the encryption keys are generated from that stored secret and random values; the random values are not stored, but are exchanged as cleartext, so the attacker would have seen them and could have stored them. Therefore, WPA2-PSK cannot achieve forward secrecy, because stealing the shared secret (the password) allows unravelling traffic which was captured beforehand (provided that the attacker recorded the whole conversation between client and access point, beginning with the four-way handshake.

Note that WPA2-PSK suffers from an additional issue which is that the shared secret is a password, thus potentially breakable through exhaustive search. This is because passwords with a lot of entropy are hard to remember and type for humans, so usual passwords have low entropy. Forward secrecy is nominally about an attacker stealing a stored secret after the deed, but when the secret is subject to exhaustive search then the theft can be pure computational enumeration, without requiring the purloining of the physical piece of hardware. WPA2-PSK uses the password only through PBKDF2 with 4096 iterations, in order to make exhaustive search on passwords 4096 times slower. Nevertheless, even with a big, fat, completely randomish password (63 printable characters allow for encoding a lot of entropy), forward secrecy would not be achieved because that password is still stored in the entrails of the access point and the client systems.

To get forward secrecy, you need some tools from asymmetric cryptography. The usual method is to have some Diffie-Hellman key exchange algorithm; any pre-shared secret would then be used only for authenticating the exchange elements. This can even be made robust against offline dictionary attacks through Password Authenticated Key Exchange: PAKE protocols combine a key exchange (like Diffie-Hellman) and a password in order to do mutual authentication in a way which does not reveal to attackers anything which can be used to "try passwords at home" (roughly put, there is no password hash which can be observed by attackers). In any case, there is no asymmetric cryptography at all in WPA2-PSK, only hashing and symmetric encryption, so no forward secrecy.

  • Just out of curiosity: some access points provide a configuration setting where you can change the "Group Re-key Interval" to a non-zero/short interval (eg. 600 seconds). Does changing that provide any improvement in security/forward secrecy?
    – Nasrus
    Jan 30, 2016 at 13:56

There is no way, unfortunately.

The WPA2 key derivation is basically a two step process: First, derive a pairwise master key (PMK), and second, use the four-way handshake to (prove that parties derived the same PMK and to) derive the final keys used for this connection. The four-way handshake is fixed in WPA2 and does not provide any forward secrecy. So all flexibility of WPA2 is in the first step, but WPA2-PSK defines it by using a hash of the PSK as PMK (more precisely PBDKF2 with only 4096 iterations is used). Thus there is also no perfect forward secrecy introduced.

If you want to know more about the security properties of WPA2 you have to read a little background material [1]. That is because even though the actual protocol of WPA2 is fairly simple from a cryptographic standpoint, its description is divided into several layers of abstraction and littered with special terminology.

[1] Take a look at those in https://security.stackexchange.com/a/17782/10727 for example.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .