from the site: http://www.netmux.com/blog/how-to-build-a-password-cracking-rig - they used 4 GPUs:

Hashtype: Keepass 1 (AES/Twofish) and Keepass 2 (AES) Speed.Dev.#*.....: 416.5 kH/s

Hashtype: sha512crypt, SHA512(Unix) Speed.Dev.#*.....:  452.4 kH/s

Hashtype: bcrypt, Blowfish(OpenBSD) Speed.Dev.#*.....: 43551 H/s
Hashtype: WPA/WPA2 Speed.Dev.#*.....: 1190.5 kH/s
Hashtype: MD5 Speed.Dev.#*.....: 76526.9 MH/s

Does this mean that with 1 GPU we can brute-force (at least try to brute) 452.4 × 1000 ÷ 4 = ~113100 passwords (stored in sha512crypt) per second?

The / 4 is ok is "H/s" the same as "P/s"? or do we need further calculations for getting the passwords/sec? (asking because there are rounds/iterations in sha512crypt)

  • Depends on the GPU and the number of iterations, but that figure looks about right for an average GPU and the default (5000) iterations.
    – grc
    Feb 25, 2017 at 12:06

2 Answers 2


Yes. The Dev.#* they list is Hashcat's way of showing the combined cracking speed of all GPU devices. Normally the Hashcat benchmark output would look like this:

Hashtype: sha512crypt, SHA512(Unix)

Speed.Dev.#1.:   147.5 kH/s (103.12ms)
Speed.Dev.#2.:   138.1 kH/s (102.84ms)
Speed.Dev.#3.:   148.0 kH/s (102.83ms)
Speed.Dev.#4.:   148.3 kH/s (102.57ms)
Speed.Dev.#*.:   581.9 kH/s

Which better shows the individual device speeds as well as the combined speed.

You're also correct that kH/s means the associated number represents thousands of hashes per second, with MH/s representing millions, GH/s representing billions, etc. And yes, the H/s measures how many different password guess to hash conversions are made every second. So your H/S will be slower for an algorithm like sha512crypt, compared to MD5, because it's measuring the time it takes to complete the entire hash conversion and not just one round/iteration.


Probably, yes. In this case, the four-GPU performance is probably four times that of a single-GPU application.

Note that this is not generally the case. Most algorithms don't scale to more processors all that well, since they need some kind of coordination of data, and that will just add overhead. Others again, can work very well on partitions of the overall problem, and distributing the workload to multiple relatively independent computing units (such as GPUs) can even have superscalar effects.

  • I'm not aware of any password hashes that suffer from the problem you mention in the first two sentences of your second paragraph. Can you provide some examples?
    – PwdRsch
    Feb 25, 2017 at 16:28
  • 2
    take any algorithm that is somewhat memory-bandwidth limited. Now add competing access from 2 compute units. Result: their performance is not 2x the performance of a single unit. Typical example: anything that works with precomputed rainbow tables in RAM. Feb 25, 2017 at 17:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .