Mathematics of cyclic redundancy checks

The cyclic redundancy check (CRC) is a check of the remainder after division in the ring of polynomials over GF(2) (the finite field of integers modulo 2). That is, the set of polynomials where each coefficient is either zero or one, and arithmetic operations wrap around.

Any string of bits can be interpreted as the coefficients of a polynomial of this sort, and a message has a valid CRC if it divisible by (i.e. is a multiple of) an agreed-on generator polynomial. CRCs are convenient and popular because they have good error-detection properties and such a multiple may be easily constructed from any message polynomial by appending an -bit remainder polynomial to produce , where is the degree of the generator polynomial.

Although the separation of into the message part and the checksum part is convenient for use of CRCs, the error-detection properties do not make a distinction; errors are detected equally anywhere within .

Formulation

In general, computation of CRC corresponds to Euclidean division of polynomials over GF(2):

Here is the original message polynomial and is the degree- generator polynomial. The bits of are the original message with zeroes added at the end. The CRC 'checksum' is formed by the coefficients of the remainder polynomial whose degree is strictly less than . The quotient polynomial is of no interest. Using modulo operation, it can be stated that

In communication, the sender attaches the bits of R after the original message bits of M, which could be shown to be equivalent to sending out (the codeword). The receiver, knowing , divides by and checks that the remainder is zero. If it is, the receiver discards (the last bits) and assumes the received message bits are correct.

Software implementations sometimes separate the message into its parts and compare the received to a value reconstructed from the received message, but hardware implementations invariably find the full-length division described above to be simpler.

In practice CRC calculations most closely resemble long division in binary, except that the subtractions involved do not borrow from more significant digits, and thus become exclusive or operations.

A CRC is a checksum in a strict mathematical sense, as it can be expressed as the weighted modulo-2 sum of per-bit syndromes, but that word is generally reserved more specifically for sums computed using larger moduli, such as 10, 256, or 65535.

CRCs can also be used as part of error-correcting codes, which allow not only the detection of transmission errors, but the reconstruction of the correct message. These codes are based on closely related mathematical principles.

Polynomial arithmetic modulo 2

Since the coefficients are constrained to a single bit, any math operation on CRC polynomials must map the coefficients of the result to either zero or one. For example, in addition:

Note that is equivalent to zero in the above equation because addition of coefficients is performed modulo 2:

Polynomial addition modulo 2 is the same as bitwise XOR. Since XOR is the inverse of itself, polynominal subtraction modulo 2 is the same as bitwise XOR too.

Multiplication is similar (a carry-less product):

We can also divide polynomials mod 2 and find the quotient and remainder. For example, suppose we're dividing by . We would find that

In other words,

The division yields a quotient of with a remainder of −1, which, since it is odd, has a last bit of 1.

In the above equations, represents the original message bits 111, is the generator polynomial, and the remainder (equivalently, ) is the CRC. The degree of the generator polynomial is 1, so we first multiplied the message by to get .

Variations

There are several standard variations on CRCs, any or all of which may be used with any CRC polynomial. Implementation variations such as endianness and CRC presentation only affect the mapping of bit strings to the coefficients of and , and do not impact the properties of the algorithm.

  • The remainder on division does not need to be zero. Although all of the preceding text is written in terms of divisibility by the generator polynomial, any fixed remainder may be used and will perform just as well as a zero remainder. Most commonly, the all-ones polynomial is used, but, for example, the asynchronous transfer mode header error control field has a remainder of The one complication arises if the same hardware which generates the CRC by finding is used to check the CRC with a full-width division of The latter will not produce a remainder of 0, nor of , but of This does not make CRC checking any more difficult, you just have to know the expected pattern.
  • The long division may begin with a non-zero remainder. The remainder is generally computed using an -bit shift register holding the current remainder, while message bits are added and reduction modulo is performed. Normal division initializes the shift register to zero, but it may instead be initialized to a non-zero value. (Again, all-ones is most common, but any pattern may be used.) This is equivalent to adding (XORing) the initialization pattern with the first bits of the message before feeding them into the algorithm. The CRC equation becomes , where is the length of the message in bits. The change this imposes on is a function of the generating polynomial and the message length, .

These two variations serve the purpose of detecting zero bits added to the message. A preceding zero bit adds a leading zero coefficient to which does not change its value, and thus does not change its divisibility by the generator polynomial. By adding a fixed pattern to the first bits of a message, such extra zero bits can be detected.

Likewise, using a non-zero remainder detects trailing zero bits added to a message. If a CRC-protected message has a zero bit appended, the received polynomial is If the former is divisible by the generator polynomial, so is the latter. Using a non-zero remainder , appending a zero bit will result in the different remainder , and therefore the extra bit will be detected.

In practice, these two variations are invariably used together. They change the transmitted CRC, so must be implemented at both the transmitter and the receiver. Both ends must preset their division circuitry to all-ones, the transmitter must add the trailing inversion pattern to the result, and the receiver must expect this pattern when checking the CRC. If the receiver checks the CRC by full-length division, the remainder because the CRC of a full codeword that already includes a CRC is no longer zero. Instead, it is a fixed non-zero pattern, the CRC of the inversion pattern of ones.

These inversions are extremely common but not universally performed, even in the case of the CRC-32 or CRC-16-CCITT polynomials. They are almost always included when sending variable-length messages, but often omitted when communicating fixed-length messages, as the problem of added zero bits is less likely to arise.

Reversed representations and reciprocal polynomials

Polynomial representations

All practical CRC generator polynomials have non-zero and coefficients. It is very common to convert this to a string of binary bits by omitting the coefficient.

This bit string may then be converted to a binary number using one of two conventions:

  • The msbit-first representation has the coefficient of as the most significant bit and the coefficient of (which is always 1) as the least significant bit.
  • The lsbit-first representation has the coefficient of as the least significant bit and the coefficient of (which is always 1) as the most significant bit.

The msbit-first form is often referred to in the literature as the normal representation, while the lsbit-first is called the reversed representation. It is essential to use the correct form when implementing a CRC. If the coefficient of happens to be zero, the forms can be distinguished at a glance by seeing which end has the bit set.

For example, the degree-16 CCITT polynomial in the forms described (bits inside square brackets are included in the word representation; bits outside are implied 1 bits; vertical bars designate nibble boundaries):

16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0   coefficient
 1 [0  0  0  1 |0  0  0  0 |0  0  1  0 |0  0  0  1]  Normal                        
   [     1     |     0     |     2     |     1    ]  Nibbles of Normal
0x1021

 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16
[1  0  0  0 |0  1  0  0 |0  0  0  0 |1  0  0  0] 1   Reverse                       
[     8     |     4     |     0     |     8    ]     Nibbles of Reverse
0x8408

16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
 1 [0  0  0  0 |1  0  0  0 |0  0  0  1 |0  0  0  1]  Reciprocal                    
   [     0     |     8     |     1     |     1    ]  Nibbles of Reciprocal
0x0811

 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16   Reverse reciprocal
16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0   Koopman
[1  0  0  0 |1  0  0  0 |0  0  0  1 |0  0  0  0] 1    
[     8     |     8     |     1     |     0    ]     Nibbles
0x8810

All the well-known CRC generator polynomials of degree have two common hexadecimal representations. In both cases, the coefficient of is omitted and understood to be 1.

  • The msbit-first representation is a hexadecimal number with bits, the least significant bit of which is always 1. The most significant bit represents the coefficient of and the least significant bit represents the coefficient of .
  • The lsbit-first representation is a hexadecimal number with bits, the most significant bit of which is always 1. The most significant bit represents the coefficient of and the least significant bit represents the coefficient of .

The msbit-first form is often referred to in the literature as the normal representation, while the lsbit-first is called the reversed representation. It is essential to use the correct form when implementing a CRC. If the coefficient of happens to be zero, the forms can be distinguished at a glance by seeing which end has the bit set.

To further confuse the matter, the paper by P. Koopman and T. Chakravarty [1][2] converts CRC generator polynomials to hexadecimal numbers in yet another way: msbit-first, but including the coefficient and omitting the coefficient. This "Koopman" representation has the advantage that the degree can be determined from the hexadecimal form and the coefficients are easy to read off in left-to-right order. However, it is not used anywhere else and is not recommended due to the risk of confusion.

Reciprocal polynomials

A reciprocal polynomial is created by assigning the through coefficients of one polynomial to the through coefficients of a new polynomial. That is, the reciprocal of the degree polynomial is .

The most interesting property of reciprocal polynomials, when used in CRCs, is that they have exactly the same error-detecting strength as the polynomials they are reciprocals of. The reciprocal of a polynomial generates the same codewords, only bit reversed — that is, if all but the first bits of a codeword under the original polynomial are taken, reversed and used as a new message, the CRC of that message under the reciprocal polynomial equals the reverse of the first bits of the original codeword. But the reciprocal polynomial is not the same as the original polynomial, and the CRCs generated using it are not the same (even modulo bit reversal) as those generated by the original polynomial.

Error detection strength

The error-detection ability of a CRC depends on the degree of its generator polynomial and on the specific generator polynomial used. The "error polynomial" is the symmetric difference of the received message codeword and the correct message codeword. An error will go undetected by a CRC algorithm if and only if the error polynomial is divisible by the CRC polynomial.

  • Because a CRC is based on division, no polynomial can detect errors consisting of a string of zeroes prepended to the data, or of missing leading zeroes. However, see § Variations.
  • All single bit errors will be detected by any polynomial with at least two terms with non-zero coefficients. The error polynomial is , and is divisible only by polynomials where .
  • All two bit errors separated by a distance less than the order of the primitive polynomial which is a factor of the generator polynomial will be detected. The error polynomial in the two bit case is . As noted above, the term will not be divisible by the CRC polynomial, which leaves the term. By definition, the smallest value of such that a polynomial divides is the polynomial's order or exponent. The polynomials with the largest order are called primitive polynomials, and for polynomials of degree with binary coefficients, have order .
  • All errors in an odd number of bits will be detected by a polynomial which is a multiple of . This is equivalent to the polynomial having an even number of terms with non-zero coefficients. This capacity assumes that the generator polynomial is the product of and a primitive polynomial of degree since all primitive polynomials except have an odd number of non-zero coefficients.
  • All burst errors of length will be detected by any polynomial of degree or greater which has a non-zero term.

(As an aside, there is never reason to use a polynomial with a zero term. Recall that a CRC is the remainder of the message polynomial times divided by the CRC polynomial. A polynomial with a zero term always has as a factor. So if is the original CRC polynomial and , then

That is, the CRC of any message with the polynomial is the same as that of the same message with the polynomial with a zero appended. It is just a waste of a bit.)

The combination of these factors means that good CRC polynomials are often primitive polynomials (which have the best 2-bit error detection) or primitive polynomials of degree , multiplied by (which detects all odd numbers of bit errors, and has half the two-bit error detection ability of a primitive polynomial of degree ).[1]

Bitfilters

Analysis technique using bitfilters[1] allows one to very efficiently determine the properties of a given generator polynomial. The results are the following:

  1. All burst errors (but one) with length no longer than the generator polynomial can be detected by any generator polynomial . This includes 1-bit errors (burst of length 1). The maximum length is , when is the degree of the generator polynomial (which itself has a length of ). The exception to this result is a bit pattern the same as that of the generator polynomial.
  2. All uneven bit errors are detected by generator polynomials with even number of terms.
  3. 2-bit errors in a (multiple) distance of the longest bitfilter of even parity to a generator polynomial are not detected; all others are detected. For degrees up to 32 there is an optimal generator polynomial with that degree and even number of terms; in this case the period mentioned above is . For this means that blocks of 32,767 bits length do not contain undiscovered 2-bit errors. For uneven number of terms in the generator polynomial there can be a period of ; however, these generator polynomials (with odd number of terms) do not discover all odd number of errors, so they should be avoided. A list of the corresponding generators with even number of terms can be found in the link mentioned at the beginning of this section.
  4. All single bit errors within the bitfilter period mentioned above (for even terms in the generator polynomial) can be identified uniquely by their residual. So CRC method can be used to correct single-bit errors as well (within those limits, e.g. 32,767 bits with optimal generator polynomials of degree 16). Since all odd errors leave an odd residual, all even an even residual, 1-bit errors and 2-bit errors can be distinguished. However, like other SECDED techniques, CRCs cannot always distinguish between 1-bit errors and 3-bit errors. When 3 or more bit errors occur in a block, CRC bit error correction will be erroneous itself and produce more errors.

See also

References

  1. ^ a b c Koopman, Philip (July 2002). "32-bit cyclic redundancy codes for Internet applications" (PDF). Proceedings International Conference on Dependable Systems and Networks. pp. 459–468. CiteSeerX 10.1.1.11.8323. doi:10.1109/DSN.2002.1028931. ISBN 978-0-7695-1597-7. S2CID 14775606. Retrieved 14 January 2011. - verification of Castagnoli's results by exhaustive search and some new good polynomials
  2. ^ Koopman, Philip; Chakravarty, Tridib (June 2004). "Cyclic redundancy code (CRC) polynomial selection for embedded networks" (PDF). International Conference on Dependable Systems and Networks, 2004. pp. 145–154. CiteSeerX 10.1.1.648.9080. doi:10.1109/DSN.2004.1311885. ISBN 978-0-7695-2052-0. S2CID 793862. Retrieved 14 January 2011. – analysis of short CRC polynomials for embedded applications