SHA-256 and SHA-512 are both in the same family (SHA-2).

Latacora says to use SHA-2. If you can get away with it, SHA-512/256 instead of SHA-256. But they're all SHA-2 family hash functions.

https://latacora.micro.blog/2018/04/03/cryptographic-right-a...

No need to bikeshed this. But if you must: SHA-512/256 > SHA-384 > SHA-512 = SHA-256

If you're wondering, "Why is SHA-384 better than SHA-512 and SHA-256?" the answer is the same reason why SHA-512/256 is the most preferred option: https://blog.skullsecurity.org/2012/everything-you-need-to-k...

Additionally, the Intel SHA extensions target SHA1 and SHA-256 (but not SHA-512), which makes SHA-256 faster than SHA-512 on newer processors.

Isn't crypto fun?

I'm super confused. Are SHA-256 and SHA256 different, and if so, why in the world would this be considered a sane naming scheme?

If not, I completely do not understand the inequation you wrote, which seemingly lists SHA-256 (and -512) multiple times.

You're probably confused by "SHA-512/256", which does not mean SHA-512 or 256, but rather a truncated version of SHA-512: https://en.wikipedia.org/wiki/SHA-2 in the third paragraph.

So why would a truncated version of SHA-512 be better than SHA-512? And why is SHA-512 = SHA-256?

Truncated hash functions are not vulnerable to length-extension attacks.

Length-extension attacks are relevant when you design a MAC by passing a secret and then a message to a hash function, where only the message is known.

Truncating the hash (which is what SHA-512/256 and SHA-384 do to SHA-512) removes the ability to grab an existing hash H(k || m) (where k is unknown and m might be known) and append junk because a truncated hash does not contain sufficient information to recover the full state of the hash function in order to append new blocks.

Why do SHA-512/160 and SHA-512/128 not exist? They could be useful as drop-in replacements for SHA1 and MD5.

Because 224 bits is considered the minimum safe output length for a general purpose hash function. So they'd be drop-in replacements but still wouldn't be safe. Safer than MD5/SHA1, but not actually safe.

So rather than push off getting people to make things actually safe by providing a footgun NIST just didn't do that.

> 224 bits is considered the minimum safe output length for a general purpose hash function.

Considered by whom?

Truncating a hash function to 224 bits put it at the 112-bit security level, which is roughly equivalent to 2048-bit RSA under today's understanding of the costs of distributed cracking attacks.

There are a lot of standards organizations all over the world with various recommendations. https://www.keylength.com collates quite a few of them. Pick the one most closely relevant for your jurisdiction.

Most of them recommend 2048-bit RSA as their minimum for asymmetric security, and AES-128 / SHA-256 as their minimum for symmetric security. This is a [112, 128]-bit security lower bound.

Truncating a hash to 160 bits yields 80-bit security, which is insufficient. 128 bits (64-bit security) is out of the question.

"Cryptographic hash functions with output size of n bits usually have a collision resistance security level n/2 and preimage resistance level n."

Depending on what you're doing, "SHA-512/128" could have a 128-bit security level. But I guess it's safer to assume n/2 when making a general recommendation.

You can truncate a hash anywhere you like. But 128 bits is considered too short now.

Ah! Makes sense now, thanks.

I've edited my parent comment to consistently use hyphens.

There are six SHA-2 family hash functions:

  * SHA-224
  * SHA-256
  * SHA-384
  * SHA-512
  * SHA-512/224
  * SHA-512/256

Hope that helps. (I know it's still confusing.)

SHA-512/256 is a truncated SHA-512 that's shortened to 256 bits, it's a separate standard.

"SHA-512/256" is a single entity

I would rather call them AMD extensions, because you would only find them in all used AMD Rome style processors (Epic, Ryzen, Threadripper) but not in any useful Intel processor, but Goldmont (ie cheap Laptops).

I read the blog, but it doesn't really expand on why SHA224/384 aren't vulnerable to that attack, can you explain (or link to some place that does?)

A length-extension attack works by taking the output of a hash and using it as the starting point for a new hash; you can do this even for hashes of messages you haven't seen, minting new related hashes. Truncated SHA-2 hashes don't output the whole hash, and so you aren't given enough information to start a new related hash.

Because they're already truncated.

SHA-384 is SHA-512 with a different IV (which doesn't affect LEAs) truncated to 384 bits (which gives you 128 bits of resistance against LEAs).

SHA-224 is the same story but with SHA-256 instead (and only 32 bits of LEA resistance).

Depends on your definition of 'better'. Theoretically SHA-512 is harder to brute force than SHA-256, but 256 bits is already extremely strong, so really there is no practical safety benefit of SHA-512 over SHA-256.

On 64-bit capable processors SHA-512 has a slight performance gain over SHA-256, but only on larger inputs. However, the digest of SHA-512 is twice the size, so what you gain in processing time, you loose in storage.

You can truncate the SHA-512 digest down to 256 bits though. Cryptographic hash functions mix well and don't suffer from the truncation (except to the extent that the truncated digest is shorter, of course). You don't necessarily need more storage (after hashing completes) just because you're using a new hash function.

> but 256 bits is already extremely strong

The strength of hashes like SHA-256 doesn't just come from the number of output bits.

The 256 bits there is relevant for brute force attacks, but not more sophisticated attacks that take into account the internal structure of the hash algorithm, and in some cases "weak" values.

SHA-512 performs more "rounds" of computation than SHA-256.

Although it's impossible to compare two different hashes on rounds alone, in general a large number of rounds of the same type of hash decreases the likelihood of non-brute-force attacks finding a collision.

If you look at the literature for attacks on hashes, they will often say they could do it for a certain number of rounds, and that number increases over time as new methods are discovered.

The number of rounds in the hash design is chosen with this in mind, trying to balance being more than sufficient for future attacks yet not too slow.

Cryptographic engineers do not in fact think you should use SHA-2-512 so that you can maximize the number of times the round function is applied.

I'm not sure what that sentence means, can you rephrase it?

The analysis you have provided for why SHA-512 is superior to SHA-256 is faulty.

The analysis was only supposed to explain why the 256-bit length of the hash output is not the sole determinant of a hash's strength. The parent was saying that, that's why it's quoted in my reply.

Pity it didn't come across that way.

FWIW, the instructions in Intel SHA extensions (which are also supported on modern AMD processors starting from Ryzen onwards) only support SHA-1 and SHA-256.

SHA-256 is on the approved FIPS lists and are faster on 32-bit operating systems, which were surprisingly common in enterprise environments until recently.

People tend to be conservative in making changes for stuff like this, and don't do so until forced.

SHA-512 provides a higher security level (256 bits), but there's not much practical value in a security level higher than 128 bits. I think "better" is too strong a word here.

SHA-512 is faster than SHA-256 in software on 64-bit machines. That's a more important difference than the security level. However, there are two major caveats to consider: 1) Hash function performance is more likely to matter on cheap (non-64-bit) hardware where everything is slow, than on fancy hardware where everything is fast. 2) Some x86 and ARM chips have hardware accelerated implementations of SHA-256, but not of SHA-512.

I believe so also. Specifically, SHA-512/256 seems to be a better choice by almost every metric except 32-bit hashing speed.

SHA-256 is shorter, and there isn't much of a difference between SHA-256 and SHA-512 (they are both using SHA-2 algorithm).