Is it possible (and reasonable) to insert a 32-bit field in the "middle" of a packet, such that the overall CRC-32 of the packet is zero? I know how to put CRC fields at the beginning or end of the protected data, but can you also put it in the middle at some arbitrary point?

(context: I am working with a 90's era protocol packet that's a fixed header followed by variable length data. The last 3 bytes of the header is a field that causes the overall CRC-24 of the header to be zero. The first byte of the data is a field that causes the overall CRC-8 of the data to be zero. Now this thing is going to start sending bigger packets (from 27 bytes of data to 8K bytes of data), and I want to combine these two CRC fields into one 4-byte field that causes the CRC-32 of the packet as a whole (header plus data) to be 0, effectively putting the "checksum" in the middle of the packet.)

Hello!

Having CRC field at the end of packet was natural when it was calculated in hardware using shift register. So when you squeezed all the useful data through shift register, this shift register would keep a reminder to be transmitted at the end of the message. So technically, one just have to switch Tx data source from baseband to register. Similarly, on receiving side one pushes whole message including CRC through shift register and if there is zero reminder, the message is likely okay and can be submitted for further processing. With this scenario in mind it is very natural to have CRC at the end of the message. If you compute that in software now, you can add some crutches to place CRC field arbitrarily.

Yes, it's possible. CRCs are a linear operation on the bytes of a message, if you interpret those bytes as a polynomial over a finite field.

I don't have a "recipe" for doing exactly what you want, but here's some mathematical background that might help (also, see other parts of this series of articles):

https://www.embeddedrelated.com/showarticle/1180.p...

Hi Jon,

yes it is feasible and reasonable. There are even some communication protocols who uses "middle" CRC. It is typically the case of MVB (Multifunction Vehicle Bus) defined by IEC61375-3 norm, which includes a CRC-8 every 64 bits.

Benoit

The best reference I know for this is "Reversing CRC – Theory and Practice."

You need to compute a regular CRC up to the insertion point, and a "backwards" CRC from the end to the insertion.

This is much faster than the alternative of computing 32 CRCs (one for each single-bit n the infix CRC) and then using linearity by solving equations to get the desired 0.