On Tue, Jun 09, 2020 at 01:31:58PM -0600, Craig Partridge wrote: > Following up on notes from various folks, most notably John K. and > Christian H., about checksums and encryption-based integrity protection, I > wanted to make a couple of clarifying points. > > * If you are not worried about an adversary who seeks to alter your data in > transit, then integrity protection is a lousy method for ensuring the > received data is correct. The reality is that a checksum of width X bits > can potentially catch 10x as many errors as an integrity check of X bits > and will likely require 1/X computational power to compute. The > requirement to make an integrity check proof against an adversary makes it > less good. [Happy to explain more -- just trying to keep this note short]. While this is true, application developers who are affected by weak TCP checksums don't really have a better option, since TLS is basically all they really have off the shelf, they will get a) [many] more bits of MAC, b) therefore more protection than a 16-bit checksum could provide, c) more compute cost. > * Some folks have assumed the TCP checksum, at 16 bits, misses an error > about 1 in 2^16 times. That's not correct. There are classes of errors > that TCP catches 100% of the time (e.g. single-bit errors). There are also > classes of errors that the TCP checksum misses about 1 in 2^10 times. This > latter is because the TCP checksum is not terribly good -- a better > designed checksum would miss only about 1 in 2^16. 2-bit errors do happen. Nico --
