Can CRC32(C) ever return to 0?

Question

I'm wondering if CRC32 sum and CRC32C in particular ever return to 0? The simple answer would be "yes" given a large enough data set. However, I was wondering if there is any provisioning in CRC32C standard that would explicitly prevent this from happening.

The use case for this is that I need to be able to check if remote file is empty and all I have is its CRC32C check sum. So, in other words can I infer that if CRC32C is 0 then file is guaranteed to be empty.

If possible, please provide any reference to a standard where this is defined.

Solution 1

A zero is as likely as any other value of a CRC32 checksum. A CRC is essentially the remainder of dividing the entire input (taken as one large binary number) by a pre-selected value. If the input happens to be divisible by that value, the remainder, and thus the CRC, is zero.

Solution 2

@Yanek is almost completely correct.

Just for fun, here is a five-character sequence that gives a CRC-32C of zero: DYB|O. Here is a four-byte sequence in hex that gives zero: ab 9b e0 9b. In fact, that is the only four-byte sequence that can do so. There are no one to three-byte sequences that will give you zero. That is where @Yanek is not exactly right, in that for one, two, or three-byte sequences, zero is not just as likely. The probability of getting a zero is zero in those cases.

Comments

[usr]

Can you use your own checksum? In that case, define zero to be only used for the empty file. If zero happens to be produced by the hash function, just set it to 1.

[kay]

You know the CRC32 value but not the length of the file? Huh?

[dtoux]

@usr CRC32C algorith is highly optimized for speed and is implemented in hardware on Intel CPUs. I need this for calculations at wire speed, so custom implementation is not an option.

[dtoux]

@Kay This is just an example. The actual use case is more complicated than that.

[usr]

@dtoux you only need to append: if (crcValue == 0) crcValue = 1;. That's all.

[dtoux]

@usr that is a neat idea, thanks

[dtoux]

That is my current understanding but I'm still hoping that someone will prove me wrong :-)

[usr]

For 3 byte inputs, there are about 256 outputs that have probability zero. There is nothing special about the zero output as far as I can tell.

[Mark Adler]

There has to be a lot more than that. There are only 2^24 possible 3-byte inputs, so there has to be 2^32-2^24 == 4,278,190,080 outputs with probability zero. The rest have probability 2^-24.

[usr]

Right, I mistakenly divided the numbers instead of subtracting.

[dtoux]

@MarkAdler Thanks Mark, that is very useful.