6

I'm writing test harness for an CRC calculation library and I'm looking for reference test vectors for CRC-32C. I found plenty for CRC-32 but nothing for CRC-32C specifically. Could somebody point me to a reference?

I managed to calculate these values using online calculator from this url:

crc32c("") = 0
crc32c("The quick brown fox jumps over the lazy dog") = 0x22620404

However, I'm not even sure if my setup is correct. All I need is a reference to a reliable source that would provide few test vectors like this.

dtoux
  • 1,754
  • 3
  • 21
  • 38
  • The x86 CRC32 instruction uses CRC32C. You could create simple program to generate your own references if needed. You still need a pre-baked reference like Mark's answer to reference check your reference checker. – srking Jan 08 '14 at 16:44
  • Here's an online checker: http://checksumcalc.live.conceptcontrols.com/ The CRC32C value you need is at little-endian, reversed 0x82F63B78 in the table. – Tobu Oct 19 '16 at 10:37
  • @Tobu Very nice, thanks. – dtoux Oct 20 '16 at 13:54

3 Answers3

9

This CRC catalog provides the check value of 0xe3069283 for a CRC-32C of the sequence of ASCII characters: "123456789" (without the quotes).

Mark Adler
  • 101,978
  • 13
  • 118
  • 158
  • I came across this page myself but I couldn't figure out what the test sequence is :-) Thanks for clearing this out. – dtoux Jan 07 '14 at 16:47
  • ...and yes the value in the original question checks :-) – dtoux Jan 07 '14 at 16:57
  • The explanation of the legend params i.e. `check` is here: https://reveng.sourceforge.io/crc-catalogue/legend.htm#crc.legend.params – Raman Sep 11 '20 at 23:05
  • FYI: checksums from this catalog are in big-endian (network) order. – Raman Sep 11 '20 at 23:09
  • @Raman Well, really they're just numbers written in standard notation. Not in big or little endian. I suppose can imagine the hex digits separated into pairs, if you like. But they aren't separated into pairs. There are no bytes -- just integers in hexadecimal. – Mark Adler Sep 12 '20 at 04:26
  • @MarkAdler sure, but working backward... to get the correct the CRC-32C checksum integer of `123456789` one must interpret the 4 bytes of `0xe3069283` in big-endian order. For comparison, here is the code Guava uses to convert the checksum to bytes: https://github.com/google/guava/blob/7fd0ff50fbaf0221d9483b99db56ad604ef878d1/guava/src/com/google/common/hash/HashCode.java#L132-L135 -- as you can see, this is little endian so Guava's hex checksum on the ASCII bytes of `123456789` is "reversed": `0x839206e3`. – Raman Sep 12 '20 at 14:24
  • To clarify, your point that `0xe3069283` is simply an integer checksum in base 16 is taken. However, I think my comment is still valid, because `0xe3069283` can just as easily be interpreted as a sequence of 4 bytes in memory, in which case knowing the byte order becomes important. – Raman Sep 13 '20 at 05:19
6

Here are test data from RFC3720, which uses crc32c.

https://www.rfc-editor.org/rfc/rfc3720#appendix-B.4

Community
  • 1
  • 1
Vouze
  • 1,678
  • 17
  • 10
2

Here's a "mee too" answer with some values you can use without parsing standards. The were cross checked with Adler's MAKECRC.C and Intel's CRC intrinsics.

Adler's implementation was modified to use the the 0x82F63B78 polynomial, which has the following coefficients:

/* terms of polynomial defining this crc (except x^32): */
static int p[] = {0,6,8,9,10,11,13,14,18,19,20,22,23,25,26,27,28};

Below are String/CRC-32C pairs. Pay attention to endianess. The answers below were extracted byte-by-byte on a little-endian machine, just like a conventional digest would be presented.

{"", "\x00\x00\x00\x00"}
{"a", "\x30\x43\xd0\xc1"}
{"abc", "\xb7\x3f\x4b\x36"}
{"message digest", "\xd0\x79\xbd\x02"}
{"abcdefghijklmnopqrstuvwxyz", "\x25\xef\xe6\x9e"}
{"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789", "\x7d\xd5\x45\xa2"}
{"12345678901234567890123456789012345678901234567890123456789012345678901234567890", "\x81\x67\x7a\x47"}
{"123456789", "\x83\x92\x06\xe3"}
jww
  • 97,681
  • 90
  • 411
  • 885