CRC32 is the same for different inputs

Question

Synopsis

I calculate CRC32 of few hex inputs using :

http://www.sunshine2k.de/coding/javascript/crc/crc_js.html

and few other CRC32 calculators.

Problem

Whatever the input i give, i get the same CRC32:

aa aa 3 0 0 0 8 0 45 0 0 34 0 0 40 0 40 6 b7 e c0 a8 1 64 c0 a8 1 1 dd 95 0 50 f4 11 d8 cf 81 8e e5 e3 80 10 10 0 d6 4c 0 0 1 1 8 a f a7 bf e0 0 0 2a f9 da b3 91 bd

Result CRC value: 0x2144DF1C

aa aa 3 0 0 0 86 dd 60 0 77 b0 1 49 11 ff fe 80 0 0 0 0 0 0 0 2 b9 df 87 1b 9a 36 ff 2 0 0 0 0 0 0 0 0 0 0 0 0 0 fb 14 e9 14 e9 1 49 36 d5 0 0 0 0 0 11 0 0 0 0 0 1 8 5f 61 69 72 70 6c 61 79 4 5f 74 63 70 5 6c 6f 63 61 6c 0 0 c 0 1 5 5f 72 61 6f 70 c0 15 0 c 0 1 8 5f 61 69 72 70 6f 72 74 c0 15 0 c 0 1 7 5f 75 73 63 61 6e 73 c0 15 0 c 0 1 8 5f 73 63 61 6e 6e 65 72 c0 15 0 c 0 1 6 5f 75 73 63 61 6e c0 15 0 c 0 1 7 5f 69 70 70 75 73 62 c0 15 0 c 0 1 4 5f 69 70 70 c0 15 0 c 0 1 5 5f 69 70 70 73 c0 15 0 c 0 1 8 5f 70 72 69 6e 74 65 72 c0 15 0 c 0 1 f 5f 70 64 6c 2d 64 61 74 61 73 74 72 65 61 6d c0 15 0 c 0 1 4 5f 70 74 70 c0 15 0 c 0 1 d 5f 61 70 70 6c 65 2d 6d 6f 62 64 65 76 c0 15 0 c 0 1 8 39 30 65 33 30 37 66 63 4 5f 73 75 62 e 5f 61 70 70 6c 65 2d 6d 6f 62 64 65 76 32 c0 15 0 c 0 1 f 5f 61 70 70 6c 65 2d 70 61 69 72 61 62 6c 65 c0 15 0 c 0 1 c0 e1 0 c 0 1 c 5f 73 6c 65 65 70 2d 70 72 6f 78 79 4 5f 75 64 70 c0 1a 0 c 0 1 0 0 29 5 a0 0 0 11 94 0 c 0 4 0 8 0 c e0 ac cb 92 66 48 c2 43 4c 9f

Result CRC value: 0x2144DF1C

aa aa 3 0 0 0 8 0 45 0 0 34 0 0 40 0 40 6 b7 e c0 a8 1 64 c0 a8 1 1 dd 8f 0 50 f ff 68 34 80 1c a4 f9 80 10 10 10 73 b8 0 0 1 1 8 a f a7 ba c 0 0 2a 62 e1 2d 8a cd

Result CRC value: 0x2144DF1C

Question

Why is this happening ?

Answer 1

The CRC is a constant because the last 4 bytes of the message are the CRC for all but the last 4 bytes of the message. The CRC is a non-zero constant, in this case, 0x2144DF1C, because the CRC is being post complemented (final xor value = 0xFFFFFFFF). You'll get the same result (0x2144DF1C) for a 4 byte message of all zeroes:

00 00 00 00

What happens is the 4 bytes of zeroes are xor'ed with the initial value 0xFFFFFFFF, and then CRC is calculated for {FF FF FF FF}, resulting in 0xDEBB20E3, which is post complemented (final xor value = 0xFFFFFFFF) to get 0x2144DF1C .

To show a case where the CRC ends up = 0, I complemented the last 4 bytes (the message CRC) in the first and last examples. If you choose CRC32, then click on custom, then set final xor value = 0, you'll get CRC = 0 for these two examples:

aa aa 3 0 0 0 8 0 45 0 0 34 0 0 40 0 40 6 b7 e c0 a8 1 64 c0 a8 1 1 dd 95 0 50 f4 11 d8 cf 81 8e e5 e3 80 10 10 0 d6 4c 0 0 1 1 8 a f a7 bf e0 0 0 2a f9 25 4c 6e 42

aa aa 3 0 0 0 8 0 45 0 0 34 0 0 40 0 40 6 b7 e c0 a8 1 64 c0 a8 1 1 dd 8f 0 50 f ff 68 34 80 1c a4 f9 80 10 10 10 73 b8 0 0 1 1 8 a f a7 ba c 0 0 2a 62 1e D2 75 32

Answer 2

All of your sample inputs already include an embedded CRC32 value - you are basically verifying that value, a constant result is exactly what you'd expect assuming that all of the data is valid. That constant result isn't zero because you're calculating your CRC over more data than the embedded CRC covered - the CRC value itself for one thing, and perhaps some header/trailer bytes that weren't protected by the CRC (such bytes will have a constant effect on the CRC value assuming that the bytes themselves are constant).

Try changing any of the bytes, or adding/removing a byte - you'll get an entirely different value.

Answer 3

Collisions are not uncommon for CRC32. CRC32 is a checksum algorithm that only uses 32 bits.

A checksum should be used to verify the integrity of data. It should not be used to create unique identifiers. It's basically useful for detecting data-transmission errors.

If you need to check for errors, then use crc32.

If you need an identifier use a UUID.

If you need speed (and not a secure hash) try using 64-bit xxHash.

If you need a secure fingerprint considered using a cryptographic hash like sha256.