Correct way to hash and crack PMKID and benchmark

[Ullsokk]

Hello guys

Please tell me if this if the wrong forum -> first post.

I am writing a scientific paper for my University (TUM) about the PMKID attack [https://hashcat.net/forum/thread-7717.html]. My paper goes quite in depth about the attack and I would like some input if my thoughts are correct.

As far as I understand:
The 802.11i-2004 standard states that PMKID = HMAC-SHA1-128(PMK, "PMK Name" || MAC_AP || MAC_STA), where the PMK is the password for the WPA/WPA2 PSK network. 

And that hcxpcaptool extracts the PMKID to <PMKID>⁎<MAC_AP>⁎<MAC_Station>⁎<ESSID>, where <PMKID> is the hashed form of the password or PMK. 

hashcat then inserts the chosen PMK/password from a dictionary/password list into HMAC-SHA1-128(<1. password>, "[b]<1. password>" || MAC_AP || MAC_STA) [/b]and from there check if the calculated PMKID equals the PMKID received from the AP. If it does not match, retry with the next password. I would like your thoughts if I am on the correct track or completely off.

I further see that the PMKID is cracked with hash type WPA-PMKID-PBKDF2 which is a network protocol. Can anyone tell me if this protocol or how you can look at it uses HMAC-SHA1-128 to hash a PMKID as stated in the previous paragraph? 

As far I have seen there is no documentation on how the PMKID is actually cracked and that is why I am asking in this forum.

My last question is about the benchmark function in hashcat. The results from the benchmark show how many passwords to hash conversions are done per second (H/s). This is normal when cracking in a high-end rig, but the goal of the attack is to crack the PMKID in a laptop, which does not pack that much power. In this case, the hash mode 16801 is used which need a premade hashed password list.

My question and wondering here is if H/s is still valid because passwords are not hashed, but only checked against each other, meaning faster checking time. I would think that H/s is not valid, because there is no hashing, but only simply string checking taking place.

Cheers and thanks for replies!

[philsmd]

I think there are a lot of misunderstandings here.

I would highly recommend that you re-read this thread again: https://hashcat.net/forum/thread-7717.html

of course -m 16800 = WPA-PMKID-PBKDF2 is not just a "string checking", nor is -m 16801 = WPA-PMKID-PMK .
If you really think that these type of algorithms mainly use "string checking", then a lot of other hash types supported by hashcat would also be just "string checking" (and they are not ! of course you compare the output/result at the end by comparing the bytes, but that is not the hard/main part. We wouldn't need GPUs for this).

This is basically what hashcat does with -m 16800:
https://github.com/hashcat/hashcat/blob/...445-L10465

and for -m 16801 "only" the pbkdf2 (first part) can be pre-computed (by a well-working/well-selected list of password candidates). This is similar to -m 2500 and -m 2501.

The second part: https://github.com/hashcat/hashcat/blob/...460-L10465 still needs to be done also for -m 16801 and this is not just "string checking", but a HMAC-SHA1 is computed.

Therefore, H/s is a perfectly fine measurement of the cracking speed for both -m 16800 and -m 16801 (and actually all other algorithms supported by hashcat).

I wouldn't say that "the goal of the attack is to crack the PMKID in a laptop". Yes, -m 16800 makes cracking of WPA passwords easier, but as always we do not recommend using laptop for any long running compute tasks because they are not designed to deal with that kind of heat/stress.

I highly recommend that you should get in contact with atom (@hashcat, jsteube on github, atom on #hashcat) or zerbea (ZerBea on github, zerbea on #hashcat) if you want any more details/suggestions etc and before you are writing/implementing/dealing with these attacks you are not really understanding 100%. It's actually not a too difficult attack to understand, but the discovery of this new attack of course is what was so great about it.