A cyclic redundancy check ( CRC) is an errordetecting code commonly used in digital networks and storage devices to detect accidental changes to raw data. Blocks of data entering these systems get a short check value attached, based on the remainder of a polynomial division of their contents. On retrieval, the calculation is repeated and, in the event the check values do not match, corrective action can be taken against data corruption. CRCs can be used for error correction (see bitfilters).
CRCs are so called because the check (data verification) value is a redundancy (it expands the message without adding information) and the algorithm is based on Cyclic code. CRCs are popular because they are simple to implement in binary hardware, easy to analyze mathematically, and particularly good at detecting common errors caused by noise in transmission channels. Because the check value has a fixed length, the function that generates it is occasionally used as a hash function.
The CRC was invented by W. Wesley Peterson in 1961; the 32bit CRC function of Ethernet and many other standards is the work of several researchers and was published in 1975.
Specification of a CRC code requires definition of a socalled generator polynomial. This polynomial becomes the divisor in a polynomial long division, which takes the message as the dividend and in which the quotient is discarded and the remainder becomes the result. The important caveat is that the polynomial are calculated according to the arithmetic of a finite field, so the addition operation can always be performed bitwiseparallel (there is no carry between digits). The length of the remainder is always less than the length of the generator polynomial, which therefore determines how long the result can be.
In practice, all commonly used CRCs employ the Galois field of two elements, GF(2). The two elements are usually called 0 and 1, comfortably matching computer architecture.
A CRC is called an nbit CRC when its check value is n bits long. For a given n, multiple CRCs are possible, each with a different polynomial. Such a polynomial has highest degree n, which means it has terms. In other words, the polynomial has a length of ; its encoding requires bits. Note that most polynomial specifications either drop the MSB or LSB, since they are always 1. The CRC and associated polynomial typically have a name of the form CRC nXXX as in the table below.
The simplest errordetection system, the parity bit, is in fact a trivial 1bit CRC: it uses the generator polynomial (two terms), and has the name CRC1.
When a codeword is received or read, the device either compares its check value with one freshly calculated from the data block, or equivalently, performs a CRC on the whole codeword and compares the resulting check value with an expected residue constant.
If the CRC values do not match, then the block contains a data error.
The device may take corrective action, such as rereading the block or requesting that it be sent again. Otherwise, the data is assumed to be errorfree (though, with some small probability, it may contain undetected errors; this is the fundamental nature of errorchecking).
Firstly, as there is no authentication, an attacker can edit a message and recompute the CRC without the substitution being detected. When stored alongside the data, CRCs and cryptographic hash functions by themselves do not protect against intentional modification of data. Any application that requires protection against such attacks must use cryptographic authentication mechanisms, such as message authentication codes or digital signatures (which are commonly based on cryptographic hash functions).
Secondly, unlike cryptographic hash functions, CRC is an easily reversible function, which makes it unsuitable for use in digital signatures.
Thirdly, CRC is a linear function with a property that
as a result, even if the CRC is encrypted with a stream cipher that uses Exclusive or as its combining operation (or mode of block cipher which effectively turns it into a stream cipher, such as OFB or CFB), both the message and the associated CRC can be manipulated without knowledge of the encryption key; this was one of the wellknown design flaws of the Wired Equivalent Privacy (WEP) protocol.
'''Function''' CRC32 '''Input:''' data: Bytes '''Array of bytes''' '''Output:''' crc32: UInt32 '''32bit unsigned crc32 value'''
'''Initialize crc32 to starting value''' crc32 ← 0xffffffff
'''for each''' byte '''in''' data '''do''' nLookupIndex ← (crc32 xor byte) and 0xFF; crc32 ← (crc32 shr 8) xor CRCTable[nLookupIndex] '''//CRCTable is an array of 256 32bit constants'''
'''Finalize the CRC32 value by inverting all the bits''' crc32 ← crc32 xor 0xFFFFFFFF '''return''' crc32
In this example, we shall encode 14 bits of message with a 3bit CRC, with a polynomial . The polynomial is written in binary as the coefficients; a 3rdorder polynomial has 4 coefficients (). In this case, the coefficients are 1, 0, 1 and 1. The result of the calculation is 3 bits long.
Start with the message to be encoded:
11010011101100
This is first padded with zeros corresponding to the bit length n of the CRC. Here is the first calculation for computing a 3bit CRC:
11010011101100 000 < input right padded by 3 bits 1011 < divisor (4 bits) = x³ + x + 1  01100011101100 000 < result
The algorithm acts on the bits directly above the divisor in each step. The result for that iteration is the bitwise XOR of the polynomial divisor with the bits above it. The bits not above the divisor are simply copied directly below for that step. The divisor is then shifted one bit to the right, and the process is repeated until the divisor reaches the righthand end of the input row. Here is the entire calculation:
11010011101100 000 < input right padded by 3 bits 1011 < divisor 01100011101100 000 < result (note the first four bits are the XOR with the divisor beneath, the rest of the bits are unchanged)1011 < divisor ...00111011101100 000101100010111101100 000101100000001101100 000 < note that the divisor moves over to align with the next 1 in the dividend (since quotient for that step was zero)1011 (in other words, it doesn't necessarily move one bit per iteration)00000000110100 000101100000000011000 000101100000000001110 000101100000000000101 000101 1 00000000000000 100 < remainder (3 bits). Division algorithm stops here as dividend is equal to zero.
Since the leftmost divisor bit zeroed every input bit it touched, when this process ends the only bits in the input row that can be nonzero are the n bits at the righthand end of the row. These n bits are the remainder of the division step, and will also be the value of the CRC function (unless the chosen CRC specification calls for some postprocessing).
The validity of a received message can easily be verified by performing the above calculation again, this time with the check value added instead of zeroes. The remainder should equal zero if there are no detectable errors.
11010011101100 100 < input with check value 1011 < divisor 01100011101100 100 < result1011 < divisor ...00111011101100 100......
00000000001110 100
101100000000000101 100101 10 < remainder
The following Python code outlines a function which will return the initial CRC remainder for a chosen input and polynomial, with either 1 or 0 as the initial padding. Note that this code works with string inputs rather than raw numbers:
''' Calculates the CRC remainder of a string of bits using a chosen polynomial. initial_filler should be '1' or '0'. ''' len_input = len(input_bitstring) initial_padding = initial_filler * (len(polynomial_bitstring)  1) input_padded_array = list(input_bitstring + initial_padding) polynomial_bitstring = polynomial_bitstring.lstrip('0') while '1' in input_padded_array[:len_input]: cur_shift = input_padded_array.index('1') for i in range(len(polynomial_bitstring)): if polynomial_bitstring[i] == input_padded_array[cur_shift + i]: input_padded_array[cur_shift + i] = '0' else: input_padded_array[cur_shift + i] = '1' return ''.join(input_padded_array)[len_input:]
def crc_check(input_bitstring, polynomial_bitstring, check_value):
''' Calculates the CRC check of a string of bits using a chosen polynomial. initial_filler should be '1' or '0'. ''' len_input = len(input_bitstring) initial_padding = check_value input_padded_array = list(input_bitstring + initial_padding) polynomial_bitstring = polynomial_bitstring.lstrip('0') while '1' in input_padded_array[:len_input]: cur_shift = input_padded_array.index('1') for i in range(len(polynomial_bitstring)): if polynomial_bitstring[i] == input_padded_array[cur_shift + i]: input_padded_array[cur_shift + i] = '0' else: input_padded_array[cur_shift + i] = '1' if '1' not in ''.join(input_padded_array)[len_input:]: return True else: return False
>>> crc_check('11010011101100','1011','100') True >>> crc_remainder('11010011101100','1011','0') '100'
The most important attribute of the polynomial is its length (largest degree(exponent) +1 of any one term in the polynomial), because of its direct influence on the length of the computed check value.
The most commonly used polynomial lengths are:
A CRC is called an nbit CRC when its check value is nbits. For a given n, multiple CRCs are possible, each with a different polynomial. Such a polynomial has highest degree n, and hence terms (the polynomial has a length of ). The remainder has length n. The CRC has a name of the form CRC nXXX.
The design of the CRC polynomial depends on the maximum total length of the block to be protected (data + CRC bits), the desired error protection features, and the type of resources for implementing the CRC, as well as the desired performance. A common misconception is that the "best" CRC polynomials are derived from either irreducible polynomials or irreducible polynomials times the factor , which adds to the code the ability to detect all errors affecting an odd number of bits. In reality, all the factors described above should enter into the selection of the polynomial and may lead to a reducible polynomial. However, choosing a reducible polynomial will result in a certain proportion of missed errors, due to the quotient ring having .
The advantage of choosing a primitive polynomial as the generator for a CRC code is that the resulting code has maximal total block length in the sense that all 1bit errors within that block length have different remainders (also called syndromes) and therefore, since the remainder is a linear function of the block, the code can detect all 2bit errors within that block length. If $r$ is the degree of the primitive generator polynomial, then the maximal total block length is $2\; ^\; \{r\}\; \; 1$, and the associated code is able to detect any singlebit or doublebit errors.
A polynomial $g(x)$ that admits other factorizations may be chosen then so as to balance the maximal total blocklength with a desired error detection power. The are a powerful class of such polynomials. They subsume the two examples above. Regardless of the reducibility properties of a generator polynomial of degree r, if it includes the "+1" term, the code will be able to detect error patterns that are confined to a window of r contiguous bits. These patterns are called "error bursts".
These complications mean that there are three common ways to express a polynomial as an integer: the first two, which are mirror images in binary, are the constants found in code; the third is the number found in Koopman's papers. In each case, one term is omitted. So the polynomial $x^4\; +\; x\; +\; 1$ may be transcribed as:
+ Examples of CRC Representations  
CRC4  0x3  0xC  0x9 
The polynomials commonly applied are not the most efficient ones possible. Since 1993, Koopman, Castagnoli and others have surveyed the space of polynomials between 3 and 64 bits in size,
finding examples that have much better performance (in terms of Hamming distance for a given message size) than the polynomials of earlier protocols, and publishing the best of these with the aim of improving the error detection capacity of future standards. In particular, iSCSI and SCTP have adopted one of the findings of this research, the CRC32C (Castagnoli) polynomial.The design of the 32bit polynomial most commonly used by standards bodies, CRC32IEEE, was the result of a joint effort for the Rome Laboratory and the Air Force Electronic Systems Division by Joseph Hammond, James Brown and ShyanShiang Liu of the Georgia Institute of Technology and Kenneth Brayer of the MITRE Corporation. The earliest known appearances of the 32bit polynomial were in their 1975 publications: Technical Report 2956 by Brayer for MITRE, published in January and released for public dissemination through DTIC in August, and Hammond, Brown and Liu's report for the Rome Laboratory, published in May. Both reports contained contributions from the other team. During December 1975, Brayer and Hammond presented their work in a paper at the IEEE National Telecommunications Conference: the IEEE CRC32 polynomial is the generating polynomial of a Hamming code and was selected for its error detection performance. Even so, the Castagnoli CRC32C polynomial used in iSCSI or SCTP matches its performance on messages from 58 bits to 131 kbits, and outperforms it in several size ranges including the two most common sizes of Internet packet. The ITUT G.hn standard also uses CRC32C to detect errors in the payload (although it uses CRC16CCITT for Physical layer).
CRC32 computation is implemented in hardware as an operation of SSE4.2 instruction set, first introduced in Intel processors' Nehalem microarchitecture.
CRC1  most hardware; also known as parity bit  0x1  0x1  0x1  0x1  rowspan="2"  
$x\; +\; 1$  
CRC3GSM  mobile networks  0x3  0x6  0x5  0x5  rowspan="2"  rowspan="2"  –  –  –  –  –  –  –  –  –  –  –  –  –  4  ∞ 
$x^3\; +\; x\; +\; 1$  
CRC4ITU  ITUT G.704, p. 12  0x3  0xC  0x9  0x9  rowspan="2"  
$x^4\; +\; x\; +\; 1$  
CRC5EPC  Gen 2 RFID (Table 6.12)  0x09  0x12  0x05  0x14  rowspan="2"  
$x^5\; +\; x^3\; +\; 1$  
CRC5ITU  ITUT G.704, p. 9  0x15  0x15  0x0B  0x1A  rowspan="2"  
$x^5\; +\; x^4\; +\; x^2\; +\; 1$  
CRC5USB  USB token packets  0x05  0x14  0x09  0x12  rowspan="2"  
$x^5\; +\; x^2\; +\; 1$  
CRC6CDMA2000A  mobile networks  0x27  0x39  0x33  0x33  
CRC6CDMA2000B  mobile networks  0x07  0x38  0x31  0x23  
CRC6DARC  Data Radio Channel  0x19  0x26  0x0D  0x2C  
CRC6GSM  mobile networks  0x2F  0x3D  0x3B  0x37  rowspan="2"  rowspan="2"  –  –  –  –  –  –  –  –  –  –  1  1  25  25  ∞ 
$x^6\; +\; x^5\; +\; x^3\; +\; x^2\; +\; x\; +\; 1$  
CRC6ITU  ITUT G.704, p. 3  0x03  0x30  0x21  0x21  rowspan="2"  
$x^6\; +\; x\; +\; 1$  
CRC7  telecom systems, ITUT G.707, ITUT G.832, MultiMediaCard, SD  0x09  0x48  0x11  0x44  rowspan="2"  
$x^7\; +\; x^3\; +\; 1$  
CRC7MVB  Train Communication Network, IEC 608705  0x65  0x53  0x27  0x72  
CRC8  DVBS2  0xD5  0xAB  0x57  0xEA  rowspan="2"  rowspan="2"  –  –  –  –  –  –  –  –  –  –  2  2  85  85  ∞ 
$x^8\; +\; x^7\; +\; x^6\; +\; x^4\; +\; x^2\; +\; 1$  
CRC8AUTOSAR  automotive integration, OpenSafety  0x2F  0xF4  0xE9  0x97  rowspan="2"  rowspan="2"  –  –  –  –  –  –  –  –  –  –  3  3  119  119  ∞ 
$x^8\; +\; x^5\; +\; x^3\; +\; x^2\; +\; x\; +\; 1$  
CRC8Bluetooth  wireless connectivity  0xA7  0xE5  0xCB  0xD3  
CRC8CCITT  ITUT I.432.1 (02/99); ATM HEC, ISDN HEC and cell delineation  0x07  0xE0  0xC1  0x83  rowspan="2"  
$x^8\; +\; x^2\; +\; x\; +\; 1$  
CRC8Dallas/Maxim  1Wire bus  0x31  0x8C  0x19  0x98  rowspan="2"  
$x^8\; +\; x^5\; +\; x^4\; +\; 1$  
CRC8DARC  Data Radio Channel  0x39  0x9C  0x39  0x9C  
CRC8GSMB  mobile networks  0x49  0x92  0x25  0xA4  
CRC8SAE J1850  AES3  0x1D  0xB8  0x71  0x8E  rowspan="2"  
$x^8\; +\; x^4\; +\; x^3\; +\; x^2\; +\; 1$  
CRC8WCDMA  mobile networks  0x9B  0xD9  0xB3  0xCD  rowspan="2"  
$x^8\; +\; x^7\; +\; x^4\; +\; x^3\; +\; x\; +\; 1$  
CRC10  ATM; ITUT I.610  0x233  0x331  0x263  0x319  rowspan="2"  
$x^\{10\}\; +\; x^9\; +\; x^5\; +\; x^4\; +\; x\; +\; 1$  
CRC10CDMA2000  mobile networks  0x3D9  0x26F  0x0DF  0x3EC  
CRC10GSM  mobile networks  0x175  0x2BA  0x175  0x2BA  
CRC11  FlexRay (4.2.8 Header CRC (11 bits))  0x385  0x50E  0x21D  0x5C2  rowspan="2"  
$x^\{11\}\; +\; x^9\; +\; x^8\; +\; x^7\; +\; x^2\; +\; 1$  
CRC12  telecom systems  0x80F  0xF01  0xE03  0xC07  rowspan="2"  
$x^\{12\}\; +\; x^\{11\}\; +\; x^3\; +\; x^2\; +\; x\; +\; 1$  
CRC12CDMA2000  mobile networks  0xF13  0xC8F  0x91F  0xF89  
CRC12GSM  mobile networks  0xD31  0x8CB  0x197  0xE98  
CRC13BBC  Time signal, Radio teleswitchhttp://www.freescale.com/files/microcontrollers/doc/app_note/AN1597.pdf  0x1CF5  0x15E7  0x0BCF  0x1E7A  rowspan="2"  
$x^\{13\}\; +\; x^\{12\}\; +\; x^\{11\}\; +\; x^\{10\}\; +\; x^7\; +\; x^6\; +\; x^5\; +\; x^4\; +\; x^2\; +\; 1$  
CRC14DARC  Data Radio Channel  0x0805  0x2804  0x1009  0x2402  
CRC14GSM  mobile networks  0x202D  0x2D01  0x1A03  0x3016  
CRC15CAN  0x4599  0x4CD1  0x19A3  0x62CC  rowspan="2"  
$x^\{15\}\; +\; x^\{14\}\; +\; x^\{10\}\; +\; x^8\; +\; x^7\; +\; x^4\; +\; x^3\; +\; 1$  
CRC15MPT1327  0x6815  0x540B  0x2817  0x740A  
CRC16Chakravarty  Optimal for payloads ≤64 bits  0x2F15  0xA8F4  0x51E9  0x978A  
CRC16ARINC  ACARS applications  0xA02B  0xD405  0xA80B  0xD015  
CRC16CCITT  X.25, V.41, HDLC FCS, XMODEM, Bluetooth, PACTOR, SD, DigRF, many others; known as CRCCCITT  0x1021  0x8408  0x811  0x8810  rowspan="2"  
$x^\{16\}\; +\; x^\{12\}\; +\; x^5\; +\; 1$  
CRC16CDMA2000  mobile networks  0xC867  0xE613  0xCC27  0xE433  
CRC16DECT  cordless telephones  0x0589  0x91A0  0x2341  0x82C4  rowspan="2"  
$x^\{16\}\; +\; x^\{10\}\; +\; x^8\; +\; x^7\; +\; x^3\; +\; 1$  
CRC16T10DIF  SCSI DIF  0x8BB7  0xEDD1  0xDBA3  0xC5DB  rowspan="2"  
$x^\{16\}\; +\; x^\{15\}\; +\; x^\{11\}\; +\; x^\{9\}\; +\; x^8\; +\; x^7\; +\; x^5\; +\; x^4\; +\; x^2\; +\; x\; +\; 1$  
CRC16DNP  DNP, IEC 870, MeterBus  0x3D65  0xA6BC  0x4D79  0x9EB2  rowspan="2"  
$x^\{16\}\; +\; x^\{13\}\; +\; x^\{12\}\; +\; x^\{11\}\; +\; x^\{10\}\; +\; x^8\; +\; x^6\; +\; x^5\; +\; x^2\; +\; 1$  
CRC16IBM  Bisync, Modbus, USB, ANSI X3.28, SIA DC07, many others; also known as CRC16 and CRC16ANSI  0x8005  0xA001  0x4003  0xC002  rowspan="2"  
$x^\{16\}\; +\; x^\{15\}\; +\; x^2\; +\; 1$  
CRC16OpenSafetyA  safety fieldbus  0x5935  0xAC9A  0x5935  0xAC9A  
CRC16OpenSafetyB  safety fieldbus  0x755B  0xDAAE  0xB55D  0xBAAD  
CRC16Profibus  fieldbus networks  0x1DCF  0xF3B8  0xE771  0x8EE7  
Fletcher16  Used in Adler32 A & B Checksums  Often confused to be a CRC, but actually a checksum; see Fletcher's checksum  
CRC17CAN  CAN FD (3.2.1 DATA FRAME)  0x1685B  0x1B42D  0x1685B  0x1B42D  
CRC21CAN  CAN FD  0x102899  0x132281  0x064503  0x18144C  
CRC24  FlexRay  0x5D6DCB  0xD3B6BA  0xA76D75  0xAEB6E5  rowspan="2"  
$x^\{24\}\; +\; x^\{22\}\; +\; x^\{20\}\; +\; x^\{19\}\; +\; x^\{18\}\; +\; x^\{16\}\; +\; x^\{14\}\; +\; x^\{13\}\; +\; x^\{11\}\; +\; x^\{10\}\; +\; x^8\; +\; x^7\; +\; x^6\; +\; x^3\; +\; x\; +\; 1$  
CRC24Radix64  OpenPGP, RTCM104v3  0x864CFB  0xDF3261  0xBE64C3  0xC3267D  rowspan="2"  
$x^\{24\}\; +\; x^\{23\}\; +\; x^\{18\}\; +\; x^\{17\}\; +\; x^\{14\}\; +\; x^\{11\}\; +\; x^\{10\}\; +\; x^7\; +\; x^6\; +\; x^5\; +\; x^4\; +\; x^3\; +\; x\; +\; 1$  
CRC30  CDMA  0x2030B9C7  0x38E74301  0x31CE8603  0x30185CE3  rowspan="2"  
$x^\{30\}\; +\; x^\{29\}\; +\; x^\{21\}\; +\; x^\{20\}\; +\; x^\{15\}\; +\; x^\{13\}\; +\; x^\{12\}\; +\; x^\{11\}\; +\; x^\{8\}\; +\; x^\{7\}\; +\; x^\{6\}\; +\; x^\{2\}\; +\; x\; +\; 1$  
CRC32  ISO 3309 (HDLC), ANSI X3.66 (ADCCP), FIPS PUB 71, FEDSTD1003, ITUT V.42, ISO/IEC/IEEE 8023 (Ethernet), SATA, MPEG2, PKZIP, Gzip, Bzip2, POSIX cksum, PNG, ZMODEM, many others  0x04C11DB7  0xEDB88320  0xDB710641  0x82608EDB  rowspan="2"  rowspan="2"  –  10  –  –  12  21  34  57  91  171  268  2974  91607  4294967263  ∞ 
$x^\{32\}\; +\; x^\{26\}\; +\; x^\{23\}\; +\; x^\{22\}\; +\; x^\{16\}\; +\; x^\{12\}\; +\; x^\{11\}\; +\; x^\{10\}\; +\; x^8\; +\; x^7\; +\; x^5\; +\; x^4\; +\; x^2\; +\; x\; +\; 1$  
(Castagnoli)  iSCSI, SCTP, G.hn payload, SSE4.2, Btrfs, ext4, Ceph  0x1EDC6F41  0x82F63B78  0x05EC76F1  0x8F6E37A0  rowspan="2"  rowspan="2"  6  –  8  –  20  –  47  –  177  –  5243  –  2147483615  –  ∞ 
$x^\{32\}\; +\; x^\{28\}\; +\; x^\{27\}\; +\; x^\{26\}\; +\; x^\{25\}\; +\; x^\{23\}\; +\; x^\{22\}\; +\; x^\{20\}\; +\; x^\{19\}\; +\; x^\{18\}\; +\; x^\{14\}\; +\; x^\{13\}\; +\; x^\{11\}\; +\; x^\{10\}\; +\; x^9\; +\; x^8\; +\; x^6\; +\; 1$  
(Koopman {1,3,28})  Excellent at Ethernet frame length, poor performance with long files  0x741B8CD7  0xEB31D82E  0xD663B05D  0xBA0DC66B  rowspan="2"  rowspan="2"  2  –  4  –  16  –  18  –  152  –  16360  –  114663  –  ∞ 
$x^\{32\}\; +\; x^\{30\}\; +\; x^\{29\}\; +\; x^\{28\}\; +\; x^\{26\}\; +\; x^\{20\}\; +\; x^\{19\}\; +\; x^\{17\}\; +\; x^\{16\}\; +\; x^\{15\}\; +\; x^\{11\}\; +\; x^\{10\}\; +\; x^\{7\}\; +\; x^\{6\}\; +\; x^\{4\}\; +\; x^\{2\}\; +\; x\; +\; 1$  
CRC32K_{2} (Koopman {1,1,30})  Excellent at Ethernet frame length, poor performance with long files  0x32583499  0x992C1A4C  0x32583499  0x992C1A4C  –  –  3  –  16  –  26  –  134  –  32738  –  65506  –  ∞  
CRC32Q  aviation; AIXM  0x814141AB  0xD5828281  0xAB050503  0xC0A0A0D5  rowspan="2"  
$x^\{32\}\; +\; x^\{31\}\; +\; x^\{24\}\; +\; x^\{22\}\; +\; x^\{16\}\; +\; x^\{14\}\; +\; x^\{8\}\; +\; x^\{7\}\; +\; x^\{5\}\; +\; x^\{3\}\; +\; x\; +\; 1$  
Adler32  Often confused to be a CRC, but actually a checksum; see Adler32  
CRC40GSM  GSM control channel ETSI TS 100 909 version 8.9.0 (January 2005), Section 4.1.2 a (Note: MpCRC.html is included with the Matpack compressed software source code, under /html/LibDoc/Crypto)  0x0004820009  0x9000412000  0x2000824001  0x8002410004  rowspan="2"  
$x^\{40\}\; +\; x^\{26\}\; +\; x^\{23\}\; +\; x^\{17\}\; +\; x^3\; +\; 1\; =\; (x^\{23\}\; +\; 1)\; (x^\{17\}\; +\; x^3\; +\; 1)$  
CRC64ECMA  ECMA182 p. 51, XZ Utils  0x42F0E1EBA9EA3693  0xC96C5795D7870F42  0x92D8AF2BAF0E1E85  0xA17870F5D4F51B49  rowspan="2"  
$x^\{64\}\; +\; x^\{62\}\; +\; x^\{57\}\; +\; x^\{55\}\; +\; x^\{54\}\; +\; x^\{53\}\; +\; x^\{52\}\; +\; x^\{47\}\; +\; x^\{46\}\; +\; x^\{45\}\; +\; x^\{40\}\; +\; x^\{39\}\; +\; x^\{38\}\; +\; x^\{37\}\; +\; x^\{35\}\; +\; x^\{33\}\; +$ $x^\{32\}\; +\; x^\{31\}\; +\; x^\{29\}\; +\; x^\{27\}\; +\; x^\{24\}\; +\; x^\{23\}\; +\; x^\{22\}\; +\; x^\{21\}\; +\; x^\{19\}\; +\; x^\{17\}\; +\; x^\{13\}\; +\; x^\{12\}\; +\; x^\{10\}\; +\; x^9\; +\; x^7\; +\; x^4\; +\; x\; +\; 1$  
CRC64ISO  ISO 3309 (HDLC), SwissProt/TrEMBL; considered weak for hashing  0x000000000000001B  0xD800000000000000  0xB000000000000001  0x800000000000000D  rowspan="2"  
$x^\{64\}\; +\; x^4\; +\; x^3\; +\; x\; +\; 1$ 

