Truncated Hash Strength

Truncating a hash is normal, permitted and specified: NIST SP 800-107 Rev. 1 says to take the leftmost $b$ bits of the full digest and states plainly what you are left with. Collision resistance falls to $b/2$ bits. Preimage resistance stays at the full $b$. The two shrink at different rates, and that asymmetry is the only thing on this page worth memorising.

The reason for the asymmetry is the birthday effect again. A truncated digest is just a hash with a smaller output space, so finding two messages that agree on the leftmost $b$ bits costs about $2^{b/2}$ — the attacker chooses both sides and the square root applies. Finding a message that maps to one given truncated digest gives the attacker no such freedom and still costs about $2^b$. Truncate SHA-256 to 128 bits and you have 64 bits of collision resistance and 128 bits of preimage resistance from the same 128 bits of output.

So the question to ask before truncating is: can an adversary choose both messages? If yes — a signature, a certificate fingerprint, a content-addressed store where users upload the content — you need collision resistance, and $b$ must be twice the strength you want. Sixty-four bits of collision resistance is within reach of a determined and moderately funded adversary, so a 128-bit truncation is not adequate for signing. If no — an HMAC tag, a password verifier, a checksum against accidental corruption — preimage resistance governs, and shorter truncations are defensible. HMAC tags truncated to 128 or even 96 bits are common and specified, precisely because the attacker cannot supply the other side.

Two traps worth naming. SHA-512/256 is not a truncation of SHA-512 in this sense. It is a distinct function: FIPS 180-4 specifies different initial hash values for it, so its output is not the leftmost 256 bits of SHA-512 and it carries its own security claim. That distinction is deliberate, and it exists so that publishing a SHA-512/256 digest tells an attacker nothing about the SHA-512 digest of the same message. Second, truncation is not the same as a shorter algorithm. Taking 224 bits of SHA-256 and using SHA-224 give different values, both perfectly good; mixing them up in a protocol produces a mismatch that looks like corruption.

For sizing, the reference is NIST SP 800-57 Part 1 Rev. 5: 112 bits of security strength is the minimum for anything protecting data past 2030, and 128 bits is the ordinary choice. Read against this page, 112 bits of collision resistance needs a 224-bit digest and 128 bits needs 256 — which is why SHA-224 and SHA-256 exist at those particular widths and not at rounder ones.