25

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:

MD5(Truncate128(SHA256_hash))

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

forest
  • 64,616
  • 20
  • 206
  • 257
H M
  • 2,897
  • 6
  • 22
  • 21
  • This thread should also mention AUTH_HMAC_SHA2_256_128 and AUTH_HMAC_SHA2_512_256, which are the names under whose [rfc8221](https://tools.ietf.org/html/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 05 '18 at 10:58

2 Answers2

22

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.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
4

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.

user25151
  • 41
  • 1
  • 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](https://en.wikipedia.org/wiki/Length_extension_attack) – 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
  • 2
    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