When transferring a large file over network, its likely that the file is broken into packets and then transferred. The underlying network protocol, lets consider the case of TLS/SSL, it generates MACs for the individual packets, the receiving party compares the MAC and is guaranteed that the MAC of individual pieces are correct. Does this ensure that the complete file on transfer is not corrupt, assuming no packet/chunk is lost on wire?

3 Answers 3


The MAC in SSL/TLS is computed over the combination of the record payload and a sequence number, thus ensuring that records are all received, with no missing, out-of-order or duplicated record. The connection is also terminated with an explicit close_notify alert, which is itself part of the protected records, thus cannot be faked by attackers.

See the standard, section

   The MAC is generated as:

      MAC(MAC_write_key, seq_num +
                            TLSCompressed.type +
                            TLSCompressed.version +
                            TLSCompressed.length +

   where "+" denotes concatenation.

      The sequence number for this record.
  • right, so, assuming there is no flaw in security does that ensures the integrity of whole file, if individual records of file are verified and assembled correctly by receiver?
    – prasun
    Commented Oct 28, 2015 at 18:58
  • 1
    The point of the sequence number is indeed to guarantee that the complete stream of bytes is correct, even if each MAC is computed only over a single record. Commented Oct 28, 2015 at 19:09
  • got you, that said, individual fragments and even re-assembling sequence numbers are protected, so, that ensures complete integrity!
    – prasun
    Commented Oct 28, 2015 at 19:14

As in the other answers, SSL/TLS protects against corruption or tampering of the file in transit.

However, it's still possible for the file to be corrupted in memory or on disk at either end, so for critical data (firmware comes to mind, where a wrong bit could brick a device), checksumming is still a very good idea - but not a 'security' issue as such.

  • +1 for considering that transmitting data is more than simply following a protocol spec. Remember also that TCP/SSL/ etc are all models. Real code has errors in it, so it never hurts to make double check that the whole equals the sum of the parts. Commented Feb 29, 2016 at 20:59
  • That too. Hadn't considered implementation errors. Commented Feb 29, 2016 at 21:04

You need to have a way to keep track of order of pieces and also make sure you get all pieces. A sequence number, checked end-to-end can probably solve this. Also, you need to make sure that no piece is replayed, so you also need to verify freshness.

  • lets say TLS/SSL is already ensuring that replays are not happening (I am talking about ideal scenarios, it would be hard to break TLS in normal scenarios as well) and I am already assuming that there is no packet drop (please see my question)
    – prasun
    Commented Oct 28, 2015 at 18:55

You must log in to answer this question.

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