4-Way Handshake vs PMKID

[kryplasemv]

why i run hcxdumptool -i wlan0mon -o test16-6.pcapng --enable_status=1

and run convert to file m 16800 it has many PBKDF2 for one ESSiD

47865d98b3c92be870908df37f070fb4*f4b8a7b83ee0*acde484f6c5f*5048554f4e47
67b8a828b7fa5df40bb6e8d9540762ce*f4b8a7b83ee0*7836cc004cd5*5048554f4e47
4c7c4d3088acc5493cc9c7a3a48cd9ee*f4b8a7b83ee0*c83c8568479b*5048554f4e47

may i run corect ? please help me!

[Mem5]

$ time hashcat -m 2500 test.hccapx --nonce-error-corrections=0 digit08
...
real 0m9,898s
user 0m7,541s
sys 0m0,933s

$ time hashcat -m 16800 test.16800 digit08
...
real 0m5,127s
user 0m2,792s
sys 0m0,821s

looking faster, for me!

The main time for computation is in the PBKDF2 (99.99999%, well not exactly but you get the point), not anything after that. Therefore anything after that PBKDF2 can be seen as almost not existent.

So why mode 16800 is faster - almost 2 times - than mode 2500 if the main painpoint is PBKDF2 for both ?

[ZerBea]

@kryplasemv
every client will receive its own (calculated) PMKID from the access point because the MAC addresses are part of the calculation
PMKID = HMAC-SHA1-128(PMK, "PMK Name" | MAC_AP | MAC_STA)

If you receive 3 of them and MAC_AP and ESSID is the same, you can delete 2 of them and keep only one for calculation, that will make hashcat a little bit faster.

If MAC_AP, MAC_STA and ESSID are the same, but the PMKID is different,
the access point changed the PMK or
it is a Authentication Key Mangement PMKID (EAP, RADIUS, WPA3,...)

hashline:
PMKID:MAC_AP:MAC_STA:ESSID
where MAC_AP is your target access point and the (E)SSID is in HEX-ASCII.
We have some good reasons to use HEX-ASCII:
"These SSIDs can be zero to 32 octets (32 bytes) long, and are, for convenience, usually in a natural language, such as English. The 802.11 standards prior to the 2012 edition did not define any particular encoding/representation for SSIDs, which were expected to be treated and handled as an arbitrary sequence of 0–32 octets that are not limited to printable characters. The IEEE 802.11-2012 defines a tag that the SSID is UTF-8 encoded and when interpreting could contain any non-ISO basic Latin characters within it. Wireless network stacks must still be prepared to handle arbitrary values in the SSID field."

BTW:
Do not run hcxdumptool on monitor interfaces created by airmon-ng.
hcxdumptool run its own monitor mode (without using netlink library libnl).

[ZerBea]

@Mem5
The construction (PBKDF2 calculation) of the plainmasterkey (PMK) is for both hash modes (2500 and 16800) the same and take long period of CPU/GPU time. This first part is a really slow part.
BTW:
We need to calculate PBKDF2 once and can use it for PMKID and MIC (EAPOL) calculation:
https://github.com/hashcat/hashcat/issues/1816

In the second part, PMKID calculation (16800) is much faster:
PMKID = HMAC-SHA1-128(PMK, "PMK Name" | MAC_AP | MAC_STA)

than calculating a MIC from EAPOL (2500):
calculate PKE, calculate PTK, calculate MIC (encrypt message and compare MIC) for WPA1:
HMAC(EVP_sha1(), pmk, 32, pkedata, 100, ptk + p * 20, NULL);
HMAC(EVP_md5(), &ptk, 16, eapol, eapol_len, mic, NULL);
or
calculate PKE, calculate PTK, calculate MIC (encrypt message and compare MIC) for WPA2:
HMAC(EVP_sha1(), pmk, 32, pkedata, 100, ptk + p * 20, NULL);
HMAC(EVP_sha1(), &ptk, 16, eapol, eapol_len, mic, NULL);
or
calculate PKE, calculate PTK, calculate MIC (encrypt message and compare MIC)  for WPA2 key version 3:
HMAC(EVP_sha256(), pmk, 32, pkedata_prf, 2 + 98 + 2, ptk, NULL);
omac1_aes_128(&ptk, eapol, eapol_len, mic);

That is a simple and quick answer, but you can read more here:
https://www.ins1gn1a.com/understanding-w...-cracking/

[Mem5]

I see. Thanks a lot!