# Is XORing a SHA256 better than truncating it? [duplicate]

Let say I want to truncate SHA256 to 128 bits. What would be the best way to minimize a probability of a collision and improve collision resistance?

1. Taking the last 16 bytes
2. Taking the first 16 bytes
3. XORing the first 16 bytes and the last 16 bytes together

And should I assume that the same logic will apply for other hash functions from the SHA-2 set (like SHA516) as well as other hash functions in general, for example, SHA-1 or MD5?

• It might be reasonable if you would include what security properties you expect from the truncated hash. I don't know if that would change which one is best; however, depending on what security properties you expect, it may be that none of them would meet that goal. – poncho Aug 12 '14 at 18:20
• @poncho Yes. Thank you. I updated my answer to clarify what security properties I expect. – CoolCodeBro Aug 12 '14 at 18:38
• Now, the question I dup'ed this two doesn't talk about xor'ing the two halves; however it's the same as the other two. However, you talk about "minimize the probability of a collision"; who's generating the images? Is it someone deliberately trying to create a collision? If so, then if he also has significant amount of computational resources, he can create a collision in any of the three methods (with Pollard Rho and computing circa $2^{64}$ hashes). – poncho Aug 12 '14 at 18:45
• @poncho I don't think that other question is really a duplicate, since it doesn't even consider the possibility of using XOR. However the answer to that other question may still be applicable to this question. – kasperd Aug 12 '14 at 19:31
• 1) Just take the first 16 bytes. Simple and secure if SHA256 is. 2) Any unkeyed 128 bit hash has at most 64 bits of collision resistance. That's generally not considered secure. Either increase the size or introduce a key not known to the attacker (using HMAC-SHA-2). – CodesInChaos Aug 12 '14 at 20:12

As pointed out in an answer to an older question, SHA-224 is more or less just using the first bits of the output of SHA-256. That is just about the most official construction anyone can find.

The XOR approach is however not entirely unprecedented, for example Linux uses that approach on SHA1 in order to generate random bits.

There is real security to be gained by not using either approach, but instead use a cryptographic hash to reduce the 256 bits down to 128 bits. This would provide protection against length extension attacks.

Also worth noting is that on 64 bit architectures SHA-384 and SHA-512 are both faster than SHA-256. So you may in fact get a faster and more secure result by computing SHA-512 and then reducing that output down to 128 bits using another hash.

I do however not know which hash could be recommended for reducing the output from 256/512 bits to 128 bits.

• 1) Using a cryptographic hash doesn't gain anything if SHA256 is already a secure hash 2) Length extensions are not applicable and don't work if you truncate the output of SHA256 to 128 bits. – CodesInChaos Aug 12 '14 at 20:11
• @CodesInChaos Is there a general proof showing that no length extension attack could be possible if the output has been reduced from 256 to 128 bits? Or is it just that certain specific length extension attacks are no longer possible? – kasperd Aug 12 '14 at 20:34
• Disclaimer: I am not a crypto pro; my reasoning may be broken. The idea of length extension attacks is that it is possible to reconstruct the internal state of the hash function and continue from that point, adding more input. When you throw away a part of the internal state, you have to guess it correctly when mounting the length extension attack. When a significant part is thrown away, that becomes infeasible, @kasperd. – Palec Aug 26 '17 at 22:56