Suppose we need/prefer 128 bit hash output, for example to generate a 128 bit encryption key or, in other applications (e.g. file integrity verification), to consume less storage space.

I don't know of any new/standard/unbroken 128 bit hash function, so it seems we have to use SHA256.

Is truncating SHA256 output to 128 bits acceptable? Does such a truncated hash have a security equal to a 128 bit hash? I mean a 128 bit hash that has no known vulnerabilities; definitely not MD5!

I have an idea of how to accomplish this:


I don't know if this will have any benefit/detriment to security.

  • This thread should also mention AUTH_HMAC_SHA2_256_128 and AUTH_HMAC_SHA2_512_256, which are the names under whose rfc8221 recommends SHA-256/128 and SHA-512/256 for use in IKE/IPSec. This thread helped me understand why they might want to truncate the hash. – user185953 Sep 5 '18 at 10:58

Though SHA-256 nominally offers a 256-bit output, no weakness about it is known when the output is truncated to 128 bits, except, of course, weaknesses inherent to the shorter output length; e.g. collision resistance drops from the infeasible 2128 to the possible (but hard) 264.

This is not a generic property of hash functions(*), but it is somewhat "obvious" from how SHA-256 is defined. In particular, when NIST defined SHA-224, a hash function with a 224-bit output, they merely took SHA-256, with a distinct initialization vector, and a truncated output.

(*) It can be shown that a given secure hash function, when truncated, cannot be awfully bad, but it can still be slightly worse than expected. For SHA-256, truncation seems safe.


Like Tom just said, you can truncate SHA-256 output to 128 bits for integrity, because 128 bits is enough to reasonably avoid collisions.

However, hash functions like SHA-256 are not suited for key generation or file authenticity (only integrity).

If you want to generate a key, use something like PKBDF2 or scrypt. If you want to authenticate a file, use HMAC functions (which can rely on SHA-256).

Source: Introduction to Cryptography on Coursera.

  • 3
    If you want to generate a key from a password you need PBKDF2 or scrypt. If you want to generate it from a master key, then plain SHA-256 is fine, though good style would be HKDF. – CodesInChaos Apr 24 '13 at 20:51
  • Authenticating data is a complex topic. Sometimes you want a hash(for example for immutable files), sometimes a MAC (HMAC-SHA-2 is my favourite MAC), sometimes a digital signature depending on the desired semantics. Truncated SHA-2(k||m) is a secure MAC btw, provided you cut away enough bits. In particular SHA-512/256(k||m) is quite strong and SHA-256/128(k||m) is decent too. – CodesInChaos Apr 24 '13 at 20:54
  • You're right, there is not only one good way to authenticate data. But SHA-2(k||m) is vulnerable to length extension attacks – user25151 Apr 24 '13 at 21:04
  • I know, but the truncation prevents the length extension attack. SHA-256/128(k||m) should have a security level of around 128 bits with a 128 bit key. I wouldn't use it without looking at further analysis, but I expect it to be secure. – CodesInChaos Apr 24 '13 at 21:10
  • 1
    I also disagree with the first sentence. While 128 bits is plenty against pre-images, it only has a collision resistance of 64 bits which is borderline feasible. I certainly wouldn't trust the collision resistance of SHA-256/128. – CodesInChaos Apr 24 '13 at 21:17

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.