Please note, this is a STATIC archive of website hashcat.net from October 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.

hashcat Forum

Full Version: H/s clarification
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
This may just be a matter of semantics, but I could use the information for a research project I'm working on using hashcat. 

The way I understand it, a very simplified view of password cracking can be summed up as follows: 

1. Acquire the hash of the target password
2. Take a candidate "plaintext" password and hash it with the same algorithm used for the target hash
3. Compare the generated hash with the targeted hash
4. Repeat until the generated and targeted hash match

The majority of cracking speed benchmarks (including hashcat's "speed" output) that I have run across are displayed in the unit H/s, which stands for hashes per second. At least to me, this seems to translate to the number of hashes generated per second. If this is the case, the time required for comparison (step 3) will technically be unaccounted for if the H/s benchmark is used to back-calculate the time required to crack a password.

Is the comparison step actually ignored, or does H/s incorporate it (i.e. hashes generated and compared per second)? I would assume that the time required for comparison is much smaller than the time required for generating hashes and may not really matter in the end, but it would be nice to know.

I have spent some time searching for this answer, but if I've missed it somewhere, I apologize-just please point me in the right direction x) Any help is appreciated. Thanks!
So far so good, except this:

Quote:At least to me, this seems to translate to the number of hashes generated per second. If this is the case, the time required for comparison (step 3) will technically be unaccounted for if the H/s benchmark is used to back-calculate the time required to crack a password.

I think you let out the most important part: The human. The weak part in cracking password hashes is not the math, it's the user. Typical success rates are 50%-95% of unsalted hash leak dumps and 20%-70% of salted hash leak dumps. There's exceptions (ex: WPA) where it's more efficient to attack they keygen, but that's a corner case. However, do not try to calculate how long it takes to crack a password based on charset and password length or you will end up as many of the useless passwords strength meters.
Ahh-I see. My project is essentially comparing multiple pieces of hardware in terms of pure cracking speeds and not necessarily accuracy (i.e. I've purposely made a password that is present somewhere in my wordlist, so success is guaranteed at some point), and I obviously neglected to consider the human portion of the process. I'll be sure to mention that as well when it comes to real-world success. Regardless, as long as the time spent on comparison is negligible, H/s should be a perfectly suitable benchmark for hardware capabilities.

Thank you for the tip-and for hashcat itself! You and your team have done a fantastic job.