2

I read about message integrity using hashing.

As I know, message integrity is hashing the message content and send to the recipient. If recipient got this message, do hashing again to compare with two hashing value.

I have one question about that.

May be file size is over 100 MB or something.

In my opinion, it may take too long.

So I would like to use some fields such as file size, and creation date in hashing. Is that possible or safe way for hashing?

  • 1
    Hello and welcome to security.se. Please clarify your question: First "it may take too long" is too vague: you need to specify your purpose, second, you seem to ignore the fact that there are many hashing algorithm that you can pick depending on your needs and, lastly, you seem to be unaware of how most hash algorithm actually works (check our CRC32, for instance, it's simple to understand) – Stephane Nov 24 '16 at 7:12
  • yes. thanks, I change my question for more specific. – user1156041 Nov 24 '16 at 7:18
  • 1
    Fast cryptographic hashes can exceed 1GB/s on a modern Intel CPU (single threaded). You'd need a 10Gbit/s network for that to limit performance and those are still pretty rare. MACs (keyed hashes) can be even faster. – CodesInChaos Nov 24 '16 at 8:28
2

How can I manage the hashing for large file size? May be file size is over 100 MB or something. In my opinion, it may take too long.

If you want to verify the integrity of a file you have to run over the full file. There is no way to skip any bits because exactly these might be affected by a change. Computing the hash over a file takes exactly one sequential run over the whole file and the algorithms are designed to be fast. You probably will not get it any faster.

So I would like to use some fields such as file size, and creation date in hashing. Is that possible or safe way for hashing?

No its not. The contents of the file can be changed without affecting size and creation date. Apart from that the creation date is not a property of the file but a property of the storage, i.e. it can be changed without even affecting the file contents. This means with this proposal a matching hash does not proof integrity nor a hash mismatch shows loss of integrity.

  • Is there any other fields to use in hashing? may be file size or file creation date or modified date. – user1156041 Nov 24 '16 at 7:19
  • 1
    @user1156041: if you want to make sure that no bits have changed you have to check all bits. There is no way around. And creation date, modification date etc are just properties of the storage in the file system which have no relation to the content of the file. – Steffen Ullrich Nov 24 '16 at 7:44
  • Since the content of the file determines the hash, its size also determines the hash - if you want a hash representing meta data (e.g. file name and creation date) for the content, then you should put the meta-data inside the file you will hash (e.g. using tar, cpio, zip) and hash the composite file.. – symcbean Nov 24 '16 at 13:32
  • @symcbean: of course you should do the hash over all data you need the integrity for. But the original question asked about the message content itself and my explanation targeted this case and that you cannot replace hashing of content with hashing of meta data. – Steffen Ullrich Nov 24 '16 at 16:47
2

before your question can be answered, you have to specify why you want data integrity in the first place: protecting against accidental changes is a very different thing than protecting against adversary modification. You need also to specify in what context that validation takes place: how does the validating actor knows what the proper checksum should be.

I would like to use some fields such as file size, and creation date in hashing. Is that possible or safe way for hashing?

Generally speaking, no: that does not give you much meaningful information. These elements are called metadata: it's data about data and it's, well, a different set of data on it's own. When you read it, you implicitely trust the storage medium (file system) to provide you with accurate information. This is an assumption that is simply wrong even if you're only attempting to protect against accidental changes (not falsification).

In very limited, specific cases it could be useful: For instance, if you have a log file created on a secure server, you could use the file size/last write date to know when the file has changed and therefore know if you need to re parse it. But this implies that the information is correct, up-to-date and that you have an earlier state to compare it with.

In a more general way

As Steffen hinted, hashing can actually be very fast: you need to read the file only once and, unless you're working with very limited resources (embedded systems, etc.) the delay introduced by the hashing process itself should be minimal and way smaller than the IO operation itself in most cases (unless you're operating strictly from memory). As always, the devil is in the details: you didn't provide any information about what you intended to do so there is no way to provide a more useful answer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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