1

If I have a payload, and I calculate a crc32 value on that payload (of arbitrary size), then I juxtapose that crc value next to the payload, treat the whole thing recursively as a new payload, then calculate a crc32 value on that, and juxtapose that crc32 value next to the payload, then transmit this whole payload, and decode it (recursively) at the recieving end... does each nested crc32 calculation further decrease the probability of an error, or are any iterations/recursions above 1 totally useless?

I didn't try it yet, I want to know if it is worth the implementation effort.

mo FEAR
  • 552
  • 4
  • 8

1 Answers1

2

It would be totally useless. The second CRC-32 will always give the same value! For example, for the standard ISO-HDLC 32-bit CRC, with the CRC appended in the little-endian order, the second CRC will always be 0x2144df1c. This is a property of the mathematics of CRCs.

Mark Adler
  • 101,978
  • 13
  • 118
  • 158
  • What if 2 different CRC's are used and both are checked? Wouldn't this increase the maximum number of error bits guaranteed to be detected for a given message size, and also reduce the probability of not detecting an error? – rcgldr Apr 06 '22 at 20:59
  • 1
    Not the question asked, but I'm sure you know that yes, that would reduce the false-positive rate dramatically. As for number of error bits, you might be better off using a 64-bit CRC than two 32-bit CRCs. For different CRCs, there's no point in including the first CRC in the calculation. You would just compute both on the message, as a way of generating 64-bits of check information for that message. – Mark Adler Apr 06 '22 at 23:03
  • how/why would it give the same value? The second crc would have 4 additional bytes to consider (the previous crc that it treats as part of the payload), and it doesn't know the meaning of any bytes, so if it takes two different payloads, one identical to the other except 4 more bytes at the end, then the crc should surely generally be different? And either way, how can it be a single specific value when a payload isn't even specified in the question? – mo FEAR Apr 14 '22 at 21:24
  • As I said, this is built in to the mathematics of CRCs. If you don't believe me, try it! It doesn't matter what the content or length of the message is. crc(message + crc(message)) = constant. This assumes that the inner CRC is appended correctly. – Mark Adler Apr 14 '22 at 21:47
  • The math is that the CRC is the remainder after a certain kind of division. If you append the CRC to the message you are taking the CRC of, you are effectively subtracting the remainder. Then when you divide _that_ by the same value you used for the first CRC, the remainder is now necessarily zero. If I take 589245 and divide by 7, the remainder is 6. If I then subtract 6, I get 589239. Divide that by 7, and I get the remainder 0. I can do that process for _any_ number (the message), and the second remainder will always be 0. – Mark Adler Apr 14 '22 at 21:52
  • For CRCs we are dividing polynomials over GF(2), but the basic idea is the same. – Mark Adler Apr 14 '22 at 21:53