The length in hashcat benchmarks is always 7 except if there's a hash (like WPA) which forces it to be longer. Note that md5crypt and sha*crypt are not using any password length-based optimizations. The speed on length 15 is the same as with length 7.
-
-
-
Thanks.
@apingis reminded me that for sha256crypt there are more SHA-256 blocks to process starting at low salt and password lengths, e.g. at salt length 8 there's slowdown between password lengths 7 and 8, and then between 11 and 12. I've just confirmed this on JtR and hashcat. -
The next question is what salt length is used in hashcat's sha256crypt benchmark. ST_HASH_07400 in the source code suggests it's 16.
-
Benchmark with "-b -m 7400" on Titan X Maxwell gives 287 kH/s, but cracking of ST_HASH_07400 with "-O -w 3 -a 3 -m 7400 '?a?a?a?a?a?a?a'" gives only 181 kH/s. Any explanation? (This discrepancy means we can't use Jeremi's published hashcat benchmarks for comparison against ours.)
-
"--markov-disable" made very little difference (maybe 181 to 182 kH/s). No such discrepancy between benchmark and cracking is seen for sha512crypt (hashcat mode 1800), so our previous comparison looks valid. I'm glad I tested hashcat's sha256crypt myself before posting a new one.
-
The benchmark mode is fine. It's just using a salt of length 8 while the example hash uses the length 16. If you truncate the salt to 8 in non-benchmark mode you should see the same performance.
-
Confirmed. Getting 288 kH/s cracking a salt length 8 sha256crypt hash with mask length 7. Will use these lengths for our FPGA benchmarks.
-
This same hash, running a GTX1080 and capped at 90W, is doing 355kH/s
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.