[SAI_Peregrinus]

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.

[p1mrx]

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

Considered by whom?

[CiPHPerCoder]

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.

[p1mrx]

"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.