The procces to recover a PSK from a PMKID or a MESSAGEPAIR is divided into two parts.
A slow part which take most of the GPU cycles:
calculate the PMK by PBKDF2 function
And a fast part:
verify the calculated PMK by PMKID (HMAC_SHA1_128)
or
verify the calculated PMK by MIC, which is slower than verifying the PMK by PMKID because this is additional divided into two parts:
part one:
calculate PTK from PMK by HMAC function
part two:
verify PTK by MIC HMAC_MD5, HMAC_SHA1_128, AES_128_CBC according to WPA1, WPA2, WPA2 keyver 3))
The formulas:
Please read this related comment:
https://github.com/hashtopolis/server/is...-749482259
If we, e.g., skip the slow PBKDF2 part, we are really fast:
https://hashcat.net/forum/thread-10253-p...l#pid53647
So, regarding this, 40x extra hashed is 40% is not correct.
Please take a look at the elapsed time, which will confirm this:
I run the test on a hash file that contain
the same ESSID on all hash lines
one or more MESSAGEPAIRs and PMKIDs of the same NETWORK
one or more MESSAGEPAIRs and PMKIDs of different NETWORKs running the same ESSID.
The hash line only contain fields/values that are mandatory to calculate/recover the PSK.
The timestamp is not mandatory.
If the admin change the PSK or the ESSID, your old hash lines are useless for you.
I strongly recommend to capture new traffic rather than to use old hash files.
Hashcat doesn't need an oui file to recover the PSK and
hcxdumdptool/hcxlabtool/hcxtools is Linux only.
The two default folders to search for the oui file are:
following this philosophy:
https://hashcat.net/forum/thread-10253-p...l#pid53612
BTW:
To successful recover a PSK it is mandatory, that you understand the whole process of AUTHENTICATION rather than doing unnecessary formatting on hash lines.
A slow part which take most of the GPU cycles:
calculate the PMK by PBKDF2 function
And a fast part:
verify the calculated PMK by PMKID (HMAC_SHA1_128)
or
verify the calculated PMK by MIC, which is slower than verifying the PMK by PMKID because this is additional divided into two parts:
part one:
calculate PTK from PMK by HMAC function
part two:
verify PTK by MIC HMAC_MD5, HMAC_SHA1_128, AES_128_CBC according to WPA1, WPA2, WPA2 keyver 3))
The formulas:
Code:
Part one:
PMK = PBKDF2(PSK, ESSID, 4096)
the same on PMKID and on MIC (from EAPOL MESSAGEPAIRs) of WPA1, WPA2 and WPA2 keyversion 3
Part two on PMKID:
PMKID = HMAC_SHA1_128(PMK, “PMK Name” + AP_MAC + CL_MAC)
Part two on MIC:
PTK = CustomPRF(PMK, "Pairwise key expansion", SUM(CL_MAC, AP_MAC, SNONCE, ANONCE))
the same on WPA1 and WPA2 (SHA1_128), but not on WPA2 keyversion 3 (SHA1_256)
KCK = PTK[0:16]
MIC = HMAC_MD5(KCK, payload) on WPA1
MIC = HMAC_SHA1(KCK, payload) on WPA2
MIC = HMAC_AES_128_CBC(KCK, payload) on WPA2 keyversion 3Please read this related comment:
https://github.com/hashtopolis/server/is...-749482259
If we, e.g., skip the slow PBKDF2 part, we are really fast:
https://hashcat.net/forum/thread-10253-p...l#pid53647
So, regarding this, 40x extra hashed is 40% is not correct.
Please take a look at the elapsed time, which will confirm this:
Code:
0/887 (0.00%) Digests
real 0m7,271s
vs
0/20 (0.00%) Digests
real 0m5,291sthe same ESSID on all hash lines
one or more MESSAGEPAIRs and PMKIDs of the same NETWORK
one or more MESSAGEPAIRs and PMKIDs of different NETWORKs running the same ESSID.
The hash line only contain fields/values that are mandatory to calculate/recover the PSK.
The timestamp is not mandatory.
If the admin change the PSK or the ESSID, your old hash lines are useless for you.
I strongly recommend to capture new traffic rather than to use old hash files.
Hashcat doesn't need an oui file to recover the PSK and
hcxdumdptool/hcxlabtool/hcxtools is Linux only.
The two default folders to search for the oui file are:
Code:
local: $HOME/.hcxtools/oui.txt
system wide: /usr/share/ieee-data/oui.txthttps://hashcat.net/forum/thread-10253-p...l#pid53612
BTW:
To successful recover a PSK it is mandatory, that you understand the whole process of AUTHENTICATION rather than doing unnecessary formatting on hash lines.