6
$\begingroup$

I found a hashcat benchmark results in the internet: hashcat results:

  • SHA-384 is 17065.4 MH/s
  • SHA-512 is 17280.3 MH/s

Why does SHA-512 take less time? SHA-512 is longer and I thought it therefore needs more time and computation resources to compute the hash?

$\endgroup$
  • 9
    $\begingroup$ Benchmark results found on the internet typically include noise, so that small differences have no practical significance; that's an example. Write results as 17 GH/s and live happy. $\endgroup$ – fgrieu Nov 7 at 8:44
  • 13
    $\begingroup$ Secure hashes are designed to be fast. Faster does not mean less secure, so the title seems to be based on a misconception. Did you know that SHA-512 is often faster than SHA-256 while also being more secure? The reason is that SHA-512 is designed to use 64 bit computations while SHA-256 is designed to use 32 bit computations. Note that modern CPU's may include an SHA-256 accelerator, putting the advantage back to SHA-256 (in case you decide to test). $\endgroup$ – Maarten Bodewes Nov 7 at 11:52
  • 1
    $\begingroup$ @NeilSlater Also see from this benchmark 8x Nvidia GTX 1080 Hashcat Benchmarks. The simple reason for slightly fast can be the truncation if they use exactly the same code. For password search this speed has no much effect. $\endgroup$ – kelalaka Nov 7 at 17:42
  • 1
    $\begingroup$ the title should be changed, taking longer to compute does not mean more secure for all use cases $\endgroup$ – Richie Frame Nov 7 at 20:32
  • 5
    $\begingroup$ If the question meant to ask about the strength of SHA384 vs SHA512 as password hashing algorithms, the answer is that they are both insecure and unsuitable for that purpose. Use a method specifically designed for passwords instead. $\endgroup$ – that other guy Nov 7 at 21:22
18
$\begingroup$

The only differences in calculations are the initial value and the output size. From NIST FIPS 180-4

  1. The initial hash value, $H^{(0)}$, shall be set as specified in Sec. 5.3.4; and
  2. The 384-bit message digest is obtained by truncating the final hash value $H ^{(N)}$, to its left-most 384 bits: $$H_0^{(N)} \mathbin\|H_1^{(N)} \mathbin\|H_2^{(N)} \mathbin\|H_3^{(N)} \mathbin\|H_4^{(N)} \mathbin\| H_5^{(N)}$$

When two source codes are compared inc_hash_sha384.cl and inc_hash_sha512.cl one can see that actually, SHA-384 does less job than SHA-512. It is not coded simply truncate the SHA-512 with different initial values. For the little speed difference, one explanation can be the vectorization that helps SHA-512 during the final calculations.

In the case of password protection, the tiny difference does not make much difference. In password hashing, actually, we use specially designed password mechanisms like PBKDF2 and Argon2 which was the winner of the password hashing competition.

In the security perspective, SHA384 has resistances to length extension attack but SHA512 doesn't have. SHA384 has 128-bit resistance against the length extension attacks since the attacker needs to guess the 128-bit to perform the attack. This is due to the truncation.

The different initial value provides domain separation. With domain separation $$\operatorname{SHA384}(m) \neq \operatorname{SHA512}(m)|_{384}$$ where $|_{384}$ is the truncation.

In the case of pre-image, secondary pre-image, and collision resistance in generic attacks we have;

\begin{array}{|c|c|c|c|}\hline & \text{pre-image resistance} & \text{2. pre-image resistance} & \text{collision resistance} \\\hline \operatorname{SHA-384} & \mathcal{O}(2^{384}) & \mathcal{O}(2^{384}) & \mathcal{O}(2^{192}) \\\hline \operatorname{SHA-512} & \mathcal{O}(2^{512}) & \mathcal{O}(2^{512}) & \mathcal{O}(2^{256}) \\\hline \end{array}

The collision resistance is $\mathcal{O}(\sqrt{2^{n}}) = \mathcal{O}(2^{n/2}) $ due to the generic birthday attacks.

Therefore; SHA-512 is better in the case of pre-image, secondary pre-image, and collision resistance. SHA-512's only weakness is that it is prone to length extension attacks.

$\endgroup$
  • 3
    $\begingroup$ @NeilSlater This is pure speculation so not worth putting into the answer, but one mechanism would be if writing/reading 48 bytes causes worse cache alignment than writing/reading 64 bytes at a time. $\endgroup$ – jpa Nov 7 at 17:15
2
$\begingroup$

Why does SHA-512 take less time?

Not for cryptographically relevant reasons. Only examination of the code (source, perhaps object) could tell. Essentially, SHA-384 is SHA-512 with a different starting constant, then removing 128 bits of the result. One possibility is that this removal is in separate code using the code for SHA-512 as a subprogram. It could also be a code alignment issue, a branch taken vs not taken... Whatever the reason, it is off-topic on crypto.SE.

SHA-512 is longer and I thought it therefore needs more time and computation resources to compute the hash

Yes, SHA-512 is longer; but no, it does not need sizable more time, because internally it operates on a 512-bit result that is truncated in the end. There is almost nothing to save in not computing the 128 extra bits: about 1/4 of the last round out of 80 (that's 0.32%), and two 64-bit additions (make that 0.4%).

$\endgroup$
  • 1
    $\begingroup$ This might explain the 0.5% difference that Neil Slater observed! $\endgroup$ – Squeamish Ossifrage Nov 8 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.