Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to implement a checksum over multiple files. We can assume, that i have a package containing N files. I want to identify such a package uniquely by following calculation:

SHA256-Hash over every file.

I save the result bytes of the hash-function for every file.

And then i calculate the sha256 hash over the concatenated file-hashes. The reason, why i hash the file-hashes again is, that i want to provide a shorter footprint of the whole package.

From my point of view this should be enough to identify a package. But my knowledge concerning cryptography is really limited at all - so i wanted to ask the experts.

Thanks in advance

share|improve this question
A security problem is that altering the file names and other metadata, including streams on NTFS volumes, goes undetected. A functional problem is that the order of hashing the file's hashes matters to the final result, but is currently unspecified (solutions; specifying some order, perhaps using an auxiliary file, or alphabetical fine name order if that's portable; or sorting the intermediary hashes before rehashing). – fgrieu Nov 2 '15 at 12:48
Thanks for the advise. I really did not consider the order of the files/hashes. I'll implement that. I am just not interested in file names or appended ntfs streams. This solution is not about security. It shall detect changes to the content of the files :) Thanks again! – domdeger Nov 2 '15 at 13:16
What you're describing is basically a Merkle tree; many (most?) software packaging systems use a similar structure. So do the popular Git and Mercurial version control tools. In fact, you might just consider using one of these tools rather than reinventing this particular wheel. – rmalayter Nov 3 '15 at 1:45
Thanks @rmalayter! I share your opinion. But in my case my implementation involves a class with less than 100 lines of code. So i guess it would be "overkill" to use git or a similar tool :) But really thanks for outlining that my approach is widely used in the real world! – domdeger Nov 3 '15 at 7:35
up vote 0 down vote accepted

Yes, this is fine for verifying that the file contents match the original. You are basically using a hash list. As long as SHA-256 is collision resistant, there is no way to find a hash that would be ambiguous and refer to two or more known file sets.

In addition to the potential issues mentioned in the comments, storing just the aggregate hash value leaves you with no way to figure out which file failed to match. That is why it is common to store the intermediate hashes as well to see which file would have to be e.g. downloaded again.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.