Sign up ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

From this wiki page:

WPA and WPA2 use keys derived from an EAPOL handshake to encrypt traffic. Unless all four handshake packets are present for the session you're trying to decrypt, Wireshark won't be able to decrypt the traffic. You can use the display filter eapol to locate EAPOL packets in your capture.

I've noticed that the decryption works with (1, 2, 4) too, but not with (1, 2, 3). As far as I know the first two packets are enough, at least for what concern unicast traffic. Can someone please explain exactly how does Wireshark deal with that, in other words why does only the former sequence work, given that the fourth packet is just an acknowledgement? Also, is it guaranteed that the (1, 2, 4) will always work when (1, 2, 3, 4) works?

Test case

This is the gzipped handshake (1, 2, 4) and an ecrypted ARP packet (SSID: SSID, password: password) in base64 encoding:


Decode with:

$ base64 -d | gunzip > handshake.cap

Run tshark to see if it correctly decrypt the ARP packet:

$ tshark -r handshake.cap -o wlan.enable_decryption:TRUE -o wlan.wep_key1:wpa-pwd:password:SSID

It should print:

  1   0.000000 D-Link_a7:8e:b4 -> HonHaiPr_22:09:b0 EAPOL Key
  2   0.006997 HonHaiPr_22:09:b0 -> D-Link_a7:8e:b4 EAPOL Key
  3   0.038137 HonHaiPr_22:09:b0 -> D-Link_a7:8e:b4 EAPOL Key
  4   0.376050 ZyxelCom_68:3a:e4 -> HonHaiPr_22:09:b0 ARP is at 00:a0:c5:68:3a:e4
share|improve this question
It can't.. it must be decrypting because it has all four, or you are connected to the wifi network and that is decrypting the packets –  Paul Apr 17 '12 at 5:22
I'm (obviously) talking about packets captured in RFMON mode. –  cYrus Apr 17 '12 at 13:17
@Paul: I've edited the question; can you reply? –  cYrus Apr 19 '12 at 9:28
I wish I could. If you follow the EAPOL sequence, the client has the PTK after only the first packet (the anonce is passed). The AP knows the PTK after the second packet (snonce). If you observe these two, and know the MACs, which of course you do, and the ssid+psk, then this should be all you need. The third packet is just GTK for broadcast and multicast, and the fourth is just an ACK. If you are decrypting unicast (which the arp-reply is) then the first two packets should be enough. I can't help but think I am missing something as everything says you need all four. –  Paul Apr 19 '12 at 11:00
Did you get any further with this? –  Paul Apr 23 '12 at 5:18

4 Answers 4

EAPOL exchanges are also used to renew the temporal keys. The new keys are installed on the Supplicant after it sends 4/4, and are installed on the Authenticator when it receives 4/4[1]. If Wireshark must handle rekeying correctly, it must only use the keys after reading the 4/4 packet in the frame, because packets may still be flowing during the rekeying (even in case where they should not, because of buffering)

For the first 4WHS, not waiting for 4/4 is possible, but it's perfectly understandable that they were just lazy to implement it. 3/4 is still necessary as it contains group keys (even if you are not interested in them, but know that you will not see ARP requests from the AP or a client for which you have no part of its 4WHS) and management keys. You may skip 3/4 too, but then you have no confirmation that the exchange was successful, because 3/4 is used to verify that the Authenticator knows the PMK.

[1] Note that with the current scheme, if the 4/4 message is lost, then the supplicant started using the new key, and the authenticator still uses the old key, and resending 3/4 encrypted with the old key will not help. This problem, among many others with WPA2, is addressed in the latest 802.11 2012 standard by keeping two keys in parallel.

share|improve this answer

Well, obviously the WireShark documentation is wrong. :-)

Going off the documentation here:

  • After EAPOL 1 and 2 both sides know the temporal key that will be used to decrypt the traffic.
  • The third message is proof that both sides know the temporal key and indicates that the Authenticator (the base station) is ready to start using the temporal key.
  • The fourth message triggers the switch from the PMK set up before the EAPOL to the temporal key derived in the EAPOL

So with that, it makes sense. WireShark doesn't need message 3 for anything. It knows the keys after messages 1 and 2, but it waits to start using them to decrypt traffic until after it receives message 4.

There are no guarantees to anything in life, especially the behavior of free software, but it's a reasonable bet that there won't be a requirement for message 3 to be present for WireShark to decrypt the session.

share|improve this answer
Seems to me that packet 4 isn't necessary either right - it is just designed to wait for it. –  Paul Apr 29 '12 at 12:02
@Paul, that's sort of like saying "resume" isn't necessary after a "pause". –  Old Pro Apr 29 '12 at 16:02
@OldPro, I'm not sure that waiting for 4° is a good idea, packets captured tend to get lost especially when they travel through the air. –  cYrus Apr 29 '12 at 18:14
@cYrus, waiting for 4 is essential, as encryption keys have to be changed simultaneously on both sides. If the client doesn't receive 4, it doesn't know that the base received 3. If the client doesn't receive 4, it sends 3 again (which triggers a resend of 4) until it either receives 4 or gives up trying to create the connection. –  Old Pro Apr 29 '12 at 18:20
@OldPro: I'm not talking about the protocol. Both sides can receive all the packets, but they might be dropped or not captured by the entity that passively captures the traffic. –  cYrus Apr 29 '12 at 18:27

This doesn't explain why, but quoting from the airdecap-ng documentation anyways,

WPA/WPA2 Requirements

The capture file must contain a valid four-way handshake. For this purpose having (packets 2 and 3) or (packets 3 and 4) will work correctly. In fact, you don't truly need all four handshake packets. 
share|improve this answer

All the information necessary to construct the PTK is exchanged in steps 1 and 2. This should be enough to decrypt unicast traffic.

Without step 3, you won't have the GTK, so decrypting multicast/broadcast won't be possible.

Step 4 isn't really necessary to decrypt capture traffic, but if there isn't a step 4, the client/AP won't start using encryption. Wireshark may key off of this before it tries to decrypt data as well.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.