Which corruptions slip past a one's-complement additive checksum on a configuration blob pushed over a serial link?

## How the check is formed Split the covered bytes into fixed-width words — 16 bits is the usual choice — add them together, and fold any carry out of the top back into the bottom. That is **one's-complement addition** with an **end-around carry**. The sender transmits the complement of the total in a trailing field; the receiver adds everything it received, the trailing field included, and expects a fixed constant. Two properties of that arithmetic explain every strength and every hole below: 1. the sum is taken **modulo 65535** for 16-bit words, so 0x0000 and 0xFFFF are two spellings of the same value, zero; 2. addition is **commutative and associative**, so the total is a function of the multiset of words, not of the sequence. ## What it always catches Any change confined to a single word alters the total by some non-zero amount modulo 65535, so the recomputed value differs and the check fails. A single flipped bit changes a word by a power of two between 1 and 32768, none of which is zero in this arithmetic; a burst that stays inside one word changes it by some other non-zero amount. The one exception is replacing an all-zero word by an all-ones word or the reverse: that adds nothing, because both are zero here. So the blind spots are never single-word events. Every one of them needs either two coordinated changes or a change that contributes nothing. ## The blind spots | Corruption | Why the check still passes | |---|---| | two whole words swapped | addition commutes, so the total ignores order | | an all-zero or all-ones word inserted or removed | such a word contributes nothing modulo 65535 | | `+d` in one word and `-d` in another | the two changes are additive inverses and cancel | | the same bit position set in one word and cleared in another | a special case of the cancelling pair | | the payload replaced by any block with the same total | the check is a function of the sum and nothing else | Each of these is missed with probability one, not with probability 2 to the power minus sixteen. That distinction is the whole point of the question: a blind spot is not a rare collision, it is a class of corruption the check is structurally unable to see. ## Why widening the field does not help The check maps a block onto a small commutative group, and whatever the group forgets, the check forgets. Order is forgotten because the operation commutes. The identity element is invisible because adding it changes nothing. Inverse pairs vanish because that is what inverses do. A 32-bit additive sum has exactly the same three holes as a 16-bit one — it only shrinks the chance that an unstructured corruption lands on the same total by accident. Closing the order hole requires changing the **shape** of the computation so that a word's position enters it, not widening the result. ## What these look like on a real link - A framing fault delivers two words of a device configuration blob in the wrong order; every field is individually valid, the trailing check agrees, and the device applies a configuration nobody wrote. - A short write leaves a zero-filled tail, or a zero-valued padding word is dropped by an intermediary. The sum is untouched, and the blob is accepted a word shorter or longer than intended. - A corruption upstream of the computation — in the sender's own buffer, before the sum is taken — is summed in as though it were intended. The check then certifies corrupt bytes, because it only ever covers the span between where it was computed and where it is verified. - An intermediary edits the blob and recomputes the trailing field. The check now certifies the last writer, not the original author; a matching value says nothing about who wrote the bytes. ## Why anyone still uses one Cost. One addition per word, no tables, no division, and the sum can be updated incrementally when a small part of the block changes. Where the expected fault really is unstructured noise on a link, an additive sum catches the overwhelming majority of it for almost nothing. The engineering answer is not to reject additive checks but to name their three holes when choosing one, and to pick a different shape when word reordering, truncation or zero padding are plausible failure modes of the path. ## In the interview A strong answer names the blind spots and attributes each to a property of the arithmetic rather than reciting them as trivia. The weak answer treats the check as a general-purpose guarantee — 'the checksum matched, so the blob is fine' — which is wrong in three separate ways and is exactly what the question is probing.