Is XORing a SHA256 better than truncating it?

Question

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?

Taking the last 16 bytes
Taking the first 16 bytes
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
May I ask what research you have done? What did you find out and where did you get stuck? Also, what exactly is the scenario? What is the reason not to use a cryptographically secure hashing function that produces a 128 bit output by default? I’m asking because we expect you to do a significant amount of research before asking here, including searching on this site for other questions and answers that might shed light on your question. At worst it will help you frame a better question; at best it will answer your question. Just an example: you mention MD5… which outputs 128 bits by nature! — e-sushi, Aug 12 '14 at 20:15
@e-sushi I don't know any cryptographically secure hashing functions, which output 128 bit by default. There is UUID version 5, which computes a SHA1 hash and ignores 38 of the output bits. But I wouldn't call that a cryptographic hash outputting 128 bits by default. — kasperd, Aug 12 '14 at 20:43
@kasperd Re.I don't know any cryptographically secure hashing functions, which output 128 bit by default. Well, maybe this can provide a hint. ;) — e-sushi, Aug 12 '14 at 20:46
@e-sushi I was checking it out already. Sounds like MD2 and RIPEMD-128 are the only contenders. Couldn't help noticing that the cited article about MD4 has a hilarious typo in the abstract: However, there were some tyops and oversights in their paper. — kasperd, Aug 12 '14 at 20:51

score 0 · Accepted Answer · edited Apr 13 '17 at 12:48

0

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.

edited Apr 13 '17 at 12:48

Community

1

answered Aug 12 '14 at 19:41

kasperd

1,377
1
10
23

3
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

1

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

Is XORing a SHA256 better than truncating it?

1 Answers1