How do I implement integrity verification using the checksum of files in a client-server protocol where the client sends multiple files to the server. I am using the following steps:

  1. The client connects to the server and sends files.
  2. In server side, when the server receives the files, I have calculated Checksum (using this) of client and server files.
  3. Then upon comparing the checksum of client and server files, integrity verification is done.

Is my process ok? Will the checksum calculation be the same if I need to calculate the checksum of video files?

  • How are the files transferred? TLS (used for HTTPS and some other high-level protocols) already has integrity checks, so that neither accidental nor malicious modification of the message (files, in this case) can occur. If you aren't using TLS or some other high-security transport protocol, then there is no way to be sure that the files aren't tampered with by a man-in-the-middle attacker. – CBHacking Nov 28 '18 at 5:10
  • I am using the TCP protocol. I was asked to verify the integrity of files by calculating the checksum. Although the code is working perfectly, I am unsure if my checksum calculation code and process is accurate. -thanks – Shamminuj Aktar Nov 28 '18 at 5:16
  • 2
    TCP, by itself, provides no security against an active network attacker (man-in-the-middle). Even if you compute the "checksum" using a cryptographically-secure hash function on both ends, and transmit that along with the files, the attacker can simply modify the files and send their new checksums instead of their original checksums, and the server will never know the difference. There exist secure "message authentication codes" and "cryptographic signatures" that an attacker cannot fake, but making them requires a way for the server to securely share a cryptographic key with the client. – CBHacking Nov 28 '18 at 5:29
  • 1
    The question is missing important information: should this check be done just to protect against accidental modification (bits flipped during transfer, connection closed early) or also against deliberate manipulation (where the attacker could also change the checksum as mentioned by CBHacking). Apart from that, video files are just a sequence of bytes from the perspective of transfer and checksum, i.e. there is no difference to other files. – Steffen Ullrich Nov 28 '18 at 5:42
  • @CBHacking, After transmission, I am calculating the checksum of client and server file separately and compare them instead of sending checksum with the transmission. Is this ensure integrity? – Shamminuj Aktar Nov 28 '18 at 5:46

Your process is not OK. How can you make sure checksum is transferred correctly or hasn't been tampered with along the way?
You need some sort of authentication before transferring file, a handshake! All this can be solved using SSL. You will not have to worry about anything.

  • I know that. But in my assignment, it is mentioned that I have to calculate the checksum. After transmission, I am calculating the checksum of client and server file separately and compare them instead of sending checksum with the transmission. Is this ensure integrity? – Shamminuj Aktar Nov 28 '18 at 5:45
  • If you are doing everything manually, meaning: 1) you send file. 2) you calculate checksum at sever. 3) you calculate checksum at client. 4) you write both checksums on a piece of paper and compare between them,,, then I don't see why integrity is not reached. But instead, I would use hash functions. Because checksums don't have strong collision resistance and usually used for small set of bytes. – daygoor Nov 28 '18 at 6:03
  • The "checksum" the OP is using is apparently SHA1 (from the link), which is not the best choice of secure hash but is definitely better than you seem to be thinking of, @daygoor. With that said, the general advice of "just use TLS, it takes care of all this for you" is valid. It's also not clear what the threat model is here; man-in-the-middle tampers with data in flight? lossy connection loses some bits? malicious client uploads malicious files? TLS solves #1, fixes #2 at what is likely to be a substantial performance hit, and does nothing (by itself) against #3. – CBHacking Dec 28 '18 at 7:28

Given the clarification in the comment (should be in question, most important bit of information!), the answer is yes.

Accidential modification is something that should in theory be quite unlikely as there is link-level CRCs in place as well as checksums in the TCP/IP stack. The theoretical chance of an accidentially modified packet passing the link layer undetected is one in four billion which sounds almost like "never going to happen" but it actually does happen not so rarely. Consider that there's quite a few packets going over the wire, not just one or two. So the TCP/IP stack should almost certainly catch the ones that make it through. Right?
Well yes, in theory. In practice, research shows that about one in 16 million packets makes it through although it shouldn't (Stone, J., Partridge, C. SIGCOMM 2000).

Although you can never reduce the likelihood of failure to zero, throwing in a SHA-1 checksum the way you suggest will lower the risk so far as to count as "does not matter". Technically it is a lie to say so, but you can consider this "guaranteed" by all practical means.

While malicious modification may be a valid concern (though it's not for you as stated), the expectation of accidentially encountering a collision on SHA-1 is outright ridiculous. This isn't going to happen during your or your childrens' or grandchildrens' lifetime.

However, do note that creating a socket that uses TLS is about 5-6 lines of code in Java (including import statements), which is not really more work than creating a plain vanilla socket, and it will also make malicious modification several orders of magnitude harder. The overhead of TLS is not that bad either, so it's usually an acceptable thing to do.

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.