I'm dreaming of a service where a client sends my service a hash of a file that they generate locally from that file. The idea is that having such a hash would be enough to show that the user is actually holding that file.

My service would rely on nobody being able to create hash collisions, preferably in the future as well. In other words, nobody should be able to create a slightly changed file (i.e. change a word in a pdf or in an image) that would generate the same hash as another file. Simple hash security stuff that all the non-broken hash functions can manage, but what I'm worried about is longevity. Would a hash generated today be still safe in 10 years?

So, my question is, would it not be a good idea to design the API so that the user would need to generate and send multiple hashes with different hash functions? Wouldn't it be a lot more difficult (even in 10 years time) to design hash collisions that collide in all those hash functions? My gut feeling is that my thinking is wrong, but I cannot figure out why it would be.

  • If you already know what hash your server wants, the easier attack would just be to send that hash to your server, bypassing any security you have on the client side. The security should rely on people not knowing what hash to send, unless they actually have the file. i.e. hash(file+salt), where salt is chosen at random. Collision attacks like you're afraid have been very, very, very expensive, even for "broken" hashes". In other words, you've got bigger fish to fry than worrying about people breaking multiple hashes. If the hash becomes insecure, just change it. Apr 27, 2018 at 19:37
  • Originally I didn't plan on keeping the source files myself on server, so updating pre-existing hashes was not a possibility. Also, I would maintain user and user<=>hash relationships on my server, so if another user would guess a hash, that wouldn't help them at all.
    – vegai
    Apr 28, 2018 at 15:33
  • I'm not sure I understand how you're going to maintain this. If I know the hash of a file, how does that prevent me from just using that to fake our your software? Can you provide more detail? Apr 29, 2018 at 1:55

1 Answer 1


Given that none of the common hashes has actually a mathematically proven resistance against attacks it is not a bad idea to use multiple hashes with different algorithms at the same time. This idea is not new and there are already some place where it is used. To get the best security improvement it might be useful to use algorithms which are based on very different ideas, like SHA-2 (i.e. SHA-256, SHA-384) and SHA-3.

You must log in to answer this question.

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