The only way to corrupt a message transmitted on an encrypted link is to break the encryption. There is a tiny argument to be made that messages should be checksummed for protection even without the encryption, but these links should always be encrypted.
The chance of a 160 bit checksum being corrupted transparently by accident is simply not worth considering. The TCP checksum is definitely small enough to see accidental transparent corruption, but we are talking about very different situation with much longer checks. On Wed, Apr 8, 2020, 1:40 AM Andor Molnar <an...@apache.org> wrote: > Hi Michael, > > "Checksum itself (even cryptographic checksum) can’t guarantee data > integrity as packet in flight can be altered along with the new checksum.” > > Why? > > If either checksum or the payload was altered, the packet will be > retransmitted. Furthermore we could implement error correction codes like > Reed-Solomon in order to avoid retransmission, but I don’t have practical > experience with that, so might be a crazy idea. :) > > Andor > > > > > On 2020. Apr 8., at 3:17, Michael Han <h...@apache.org> wrote: > > > >>> but not bulletproof? > > > > tcp checksum is weak and can't detect all corrupt packet; and bit flip > can > > happen anywhere within the stack, and can be caused by malfunction of > ram, > > or say, cosmic rays. > > Statistically a corrupt packet survives all layers of check is low, and > > even a packet is corrupted, app layer behavior might still be ok. > > > >>> wire encryption probably resolves it for free. > > > > This would be my recommendation here as well to ensure data integrity > > during transmission. Checksum itself (even cryptographic checksum) can't > > guarantee data integrity as packet in flight can be altered along with > the > > new checksum. > > > > > > > > On Tue, Apr 7, 2020 at 1:37 AM Andor Molnar <an...@apache.org> wrote: > > > >> Hi Zk community, > >> > >> I’ve been looking at the following ticket for a while and made me > thinking: > >> ZOOKEEPER-2175 Checksum validation for malformed packets needs to > handle. > >> https://issues.apache.org/jira/browse/ZOOKEEPER-2175 > >> > >> It has been found in 3.4.6 originally and not resolved since then saying > >> that wire encryption probably resolves it for free. I have doubts > against > >> the issue could actually happen at all, but the evidence in the jira is > >> quite convincing. > >> > >> 1) But what if somebody don’t want the overhead of using encryption? > >> 2) How often this issue could ever happen given that TCP packets have > >> their own checksum which also protects the payload, but not bulletproof? > >> 3) Found a suggestion in a comment to send session id in the payload of > >> Ping packets, but malformed packets could happen in any other > >> communication, not just session ids. > >> 4) Does GRPC have a built-in mechanism to protect the communication? > Maybe > >> this would be the best way forward. > >> > >> What do you think? > >> > >> Andor > >> > >> > >> > >
