How do I use this CRC-32C C# library?

Question

I've downloaded this library https://github.com/robertvazan/crc32c.net for my project I'm working on. I need to use CRC in a part of my project so I downloaded the library as it is obviously going to be much faster than anything I'm going to write in the near future.

I have some understanding of how crc works, I once made a software implementation of it (as a part of learning) that worked, but I have got to be doing something incredibly stupid while trying to get this library to work and not realize it. No matter what I do, I can't seem to be able to get crc = 0 even though the arrays were not changed.

Basically, my question is, how do I actually use this library to check for integrity of a byte array?

The way I understand it, I should call Crc32CAlgorithm.Compute(array) once to compute the crc the first time and then call it again on an array that has the previously returned value appended (I've tried to append it as well as set last 4 bytes of the array to zeroes before putting the returned value there) and if the second call returns 0 the array was unchanged.

Please help me, I don't know what I'm doing wrong.

EDIT: It doesn't work right when I do this: (yes, I realize linq is very slow, this is just an example)

        using(var hash = new Crc32CAlgorithm())
        {
            var array = new byte[] { 1, 2, 3, 4, 5, 6, 7, 8 };
            var crc = hash.ComputeHash(array);
            var arrayWithCrc = array.Concat(crc).ToArray();
            Console.WriteLine(string.Join(" ", hash.ComputeHash(arrayWithCrc)));
        }

Console outputs: 199 75 103 72

A CRC adds bytes at end of original data. So if you have 96 bytes the results with CRC32 is 100 bytes. Then if you computer the CRC of the 100 bytes you usually will get all zeroes or all ones depending on the CRC properties you are using. The same algorithm (method) is use the Computer and Check. the only difference is the computer calculates over 96 bytes while the Check computers over 100 bytes. See : sunshine2k.de/coding/javascript/crc/crc_js.html. See the link on page to "Understanding and Implementing" — jdweng
@jdweng Thank you for taking your time to answer. If you would please look at the edit of my question, I've done pretty much that (at least I think) and it doesn't work for me :/ — Petrusion
You may have to invert the CRC, then append it, and expect FFFFFFFF instead of zero — harold
@harold Nice! It works that way. I've never heard about inverting the crc and expecting FFFFFFFF, and I've had multiple classes on crc at my university. Why does it work like that all the while not working the "usual" way? — Petrusion
@Petrusion there is some explanation here. In this case, since the CRC is already inverted, you're really un-inverting it to make the math work out again, and then the expected result is FFFFFFFF because that's also inverted — harold

Mark Adler Mark Adler · Accepted Answer · 2020-10-09T04:14:20

You do not need to append a CRC to a message and compute the CRC of that in order to check a CRC. Just compute the CRC on the message on one end, send that CRC along with the message, compute CRC on just the message on the other end (not including the sent CRC), and then compare the CRC you computed to the one that was sent with the message.

They should be equal to each other. That's all there is to it. That works for any hash you might use, not just CRCs.

If you feel deeply compelled to make use of the lovely mathematical property of CRCs where computing the CRC on the message with its CRC appended gives a specific result, you can. You have to append the CRC bits in the correct order, and you need to look for the "residue" of the CRC, which may not be zero.

In your case, you are in fact appending the bits in the correct order (by appending the bytes in little-endian order), and the result you are getting is the correct residue for the CRC-32C. That residue is 0x48674bc7, which separated into bytes, in little-endian order, and then converted into decimal is your 199 75 103 72.

You will find that if you take any sequence of bytes, compute the CRC-32C of that, append that CRC to the sequence in little-endian order, and compute the CRC-32C of the sequence plus CRC, you will always get 0x48674bc7.

However that's smidge slower than just comparing the two CRC's, since now you have to compute a CRC on four more bytes than before. So, really, there's no need to do it this way.

How do I use this CRC-32C C# library?

1 Answers