There are 100 bytes with a CRC16. However I only know the first 50.
I want to change byte 5 from a known value X to another value Y, and fix up the CRC16 to be valid - without knowing bytes 50-100.
This is possible with the TCP checksum, because it's just addition. But CRC16 is a polynomial. Is it still possible?
Yes, it is possible. And quite efficient, too.
$\DeclareMathOperator{\crc}{crc}$CRC is linear, meaning $\crc(x \oplus y) = \crc(x) \oplus \crc(y)$, where $\oplus$ is bitwise exclusive-or.
Suppose there's a message $m$ and we're given $\crc(m)$.
Linearity means we can effectively compute the difference in the CRC digest by computing the CRC of the difference. For example, $m \oplus 1$ is the message with the right-most bit flipped — that's how XOR works. Because of linearity
$$\crc(m \oplus 1) = \crc(m) \oplus \crc(1)$$
So by computing $\crc(1)$ and doing a little bitwise arithmetic, we can find the CRC digest for the message if we were to flip the rightmost bit... without knowing the original message at all.
The same principle applies to your question. If you know the first byte of the message is (for example) 15 and you want to change it to 8, then compute $15 \oplus 8 = 7$ and pad that value with zero bytes on the right so it lines up with the first byte of the message. Let the padded value be called $d$. Then compute $$\crc(m) \oplus \crc(d) = \crc(m \oplus d)$$ which will be the forged CRC value. The reason you right-pad with zero bytes is $x \oplus 0 = x$ for any $x$: XORing a value with zero doesn't change it.
Here's what $m \oplus d$ looks like, if it helps clarify:
$$ \begin{array}{ccc} & 15 & \text{unknown bytes} & (\leftarrow m) \\ \oplus & 7 & \text{00 00 00 ...} & (\leftarrow d) \\ \hline & 8 & \text{(same) unknown bytes} \\ \end{array} $$
(I realize using decimal instead of hex here may look a little weird, but oh well.)
The original message's first byte was 15. We wanted it to be 8 instead. We found $15 \oplus 8$ to be 7, so that's the value we right-pad with zeros, because the zeros won't affect the rest of the message. Linearity lets us pull off the trick. Of course, this technique works for any number of bytes, not just the first one.
(By the way: the need to right pad the difference with zero bytes is why we needed to know the length of the original message.)
Note: fgrieu's comment below about some CRCs having a weaker property is relevant, but doesn't materially affect the attack (set $z = 0$ in his comment to use the same attack essentially).
