31

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.

Improve this question
1
  • 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
    Commented Sep 5, 2018 at 10:58

2 Answers 2

Reset to default
29

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.

Improve this answer
1
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.

Improve this answer
5
  • 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
    Commented Apr 24, 2013 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
    Commented Apr 24, 2013 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
    Commented Apr 24, 2013 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
    Commented Apr 24, 2013 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
    Commented Apr 24, 2013 at 21:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .