01-30-2019, 02:01 PM
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.
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.