1

As TCP contains a checksum and the TCP/IP stack will detect broken packets, is it redundant to add an extra checksum or CRC in TCP packets to make it possible for the receiver verify whether the data is same with the sent one?

Some thought about this question:

1.It's very common seen that there is a sha256 value to verify the consistency when downloading files from internet.

2.The checksum contained in TCP packets already could detect broken packets in most cases.

3.The Modbus protocol for TCP dropped the CRC,which is used by the Modubs protocol for serial because of there is already a checksum in TCP packets.

So, I am really confused now. Could somebody shed some light on this question?

ADDED: After googled, it's really not a new question, but the answer is still not clear, there are two opposite voices about this question.

For details, see these:

CRC checking done automatically on Tcp/Ip?

Is it possible for packets sent using TCP to ever arrive with different data?

John
  • 149
  • 6
  • the existing checksum will detect most faults. HMAC is probably a better approach if you are worried about data tampering. – Jasen Jun 18 '21 at 05:17
  • @Jasen Why is HMAC other than CRC or BSD checksum? – John Jun 18 '21 at 06:09
  • hmac is cryptographically secure - so if you're worried about a mian in the middle messing with your messages HMAC will prevent that. – Jasen Jun 18 '21 at 06:16

1 Answers1

2

The SHA checksum is used to verify integrity, i.e. that the data was not intentionally modified, while the CRC is meant to protect against bit errors.

The CRC can not be used for tamper resistance, because it can be trivially recomputed after modifying the data.

The TCP checksum is even simpler than a CRC, so its presence is more of a formality these days. Most link level protocols have their own checksums or error correcting codes, so bit errors have become unlikely, but they used to be common with RS-232 links.

The SHA checksum alone does not provide protection, because it also needs to be transmitted, but if you can establish a secure channel for the checksum, it is possible to use an insecure channel for the bulk data and then verify it against the SHA checksum, and be reasonably sure that the data has not been tampered with.

Simon Richter
  • 3,317
  • 19
  • 19
  • Thank you for your clarification. "The CRC can not be used for tamper resistance, because it can be trivially recomputed after modifying the data." Why SHA checksum couldn't be trivially recomputed after modifying the data? – John Jun 17 '21 at 10:39
  • @John, sorry, that was the wrong way around. It is possible to compute data that matches a specific CRC, but it isn't possible to compute data that matches a specific SHA sum. – Simon Richter Jun 17 '21 at 13:02
  • ***Because*** the **probability** of **collision** for CRC is **much, much** higher than SHA. Can I think in this way? Am I right? – John Jun 17 '21 at 13:06
  • @John, CRCs are typically shorter, but a CRC with 256 bits would still not be tamper proof, because the algorithm can be reversed. – Simon Richter Jun 17 '21 at 13:36
  • @John A link level protocol is something like Ethernet, which already has a 32-bit CRC. – Michael Hampton Jun 18 '21 at 01:54
  • @SimonRichter As you say that the TCP checksum is even simpler than a CRC, so its presence is more of a formality these days, whereas the Modbus protocol for TCP dropped the CRC segment, which is used by the Modubs protocol for serial because of there is already a checksum in TCP packets. How do think about it? – John Jun 18 '21 at 13:51