Timeline for Wouldn't concatenating the result of two different hashing algorithms defeat all collisions?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 2, 2023 at 23:41 | comment | added | Vaelus | @Eddie This will depend entirely on the specific hash functions. For example, some processors implement hardware acceleration for specific hash functions, so one method may be significantly faster than the other on some hardware. In general though, assuming none of the hash functions have a known weakness, I don't think there's a strong technical reason to choose one or the other. That said, I think many people would find the decision to concatenate two cryptographic hashes perplexing in the absence of a strong technical reason, since it presumably increases implementation complexity. | |
| Mar 2, 2023 at 15:44 | comment | added | Eddie | This was the confirmation I was seeking. Thank you. Follow on question, is there a reason why doing a single 512-bit hash is "better" than concatenating two different 256-bit hashes (faster, more secure, simpler, lower cpu, anything)? | |
| Mar 2, 2023 at 15:43 | vote | accept | Eddie | ||
| Mar 2, 2023 at 6:14 | comment | added | Jeremy Friesner | Perhaps some people are sufficiently paranoid that they would prefer not to assume a uniform distribution -- e.g. if in the future it turns out that one of the hashing algorithms contains an exploitable flaw but the other algorithm does not, then using the concatenation of the two algorithms' output could be more resistant to exploitation than just using a single algorithm to generate twice the number of hash-bits? | |
| Mar 2, 2023 at 4:55 | history | answered | Vaelus | CC BY-SA 4.0 |