Comprobación de redundancia cíclica

Una comprobación de redundancia cíclica ( CRC ) es un código de detección de errores que se utiliza habitualmente en redes digitales y dispositivos de almacenamiento para detectar cambios accidentales en los datos digitales. ^{[1] [2]} A los bloques de datos que entran en estos sistemas se les adjunta un valor de comprobación breve , basado en el resto de una división polinómica de su contenido. Al recuperarlos, se repite el cálculo y, en caso de que los valores de comprobación no coincidan, se pueden tomar medidas correctivas contra la corrupción de los datos. Las CRC se pueden utilizar para la corrección de errores (consulte filtros de bits ). ^[3]

Los CRC se denominan así porque el valor de verificación de datos es una redundancia (expande el mensaje sin añadir información ) y el algoritmo se basa en códigos cíclicos . Los CRC son populares porque son sencillos de implementar en hardware binario , fáciles de analizar matemáticamente y particularmente buenos para detectar errores comunes causados ​​por ruido en los canales de transmisión. Debido a que el valor de verificación tiene una longitud fija, la función que lo genera se utiliza ocasionalmente como una función hash .

Los CRC se basan en la teoría de códigos cíclicos de corrección de errores . El uso de códigos cíclicos sistemáticos , que codifican mensajes añadiendo un valor de comprobación de longitud fija, con el fin de detectar errores en redes de comunicación, fue propuesto por primera vez por W. Wesley Peterson en 1961. ^[4] Los códigos cíclicos no sólo son sencillos de implementar, sino que tienen la ventaja de ser especialmente adecuados para la detección de errores de ráfaga : secuencias contiguas de símbolos de datos erróneos en los mensajes. Esto es importante porque los errores de ráfaga son errores de transmisión comunes en muchos canales de comunicación , incluidos los dispositivos de almacenamiento magnético y óptico. Normalmente, un CRC de n bits aplicado a un bloque de datos de longitud arbitraria detectará cualquier ráfaga de error individual no superior a n bits, y la fracción de todas las ráfagas de error más largas que detectará es aproximadamente (1 − 2 ^{− n} ) .

La especificación de un código CRC requiere la definición de un polinomio generador . Este polinomio se convierte en el divisor de una división larga polinómica , que toma el mensaje como dividendo y en la que se descarta el cociente y el resto se convierte en el resultado. La salvedad importante es que los coeficientes polinómicos se calculan de acuerdo con la aritmética de un cuerpo finito , por lo que la operación de suma siempre se puede realizar en paralelo bit a bit (no hay acarreo entre dígitos).

En la práctica, todos los CRC de uso común emplean el campo finito de dos elementos, GF(2) . Los dos elementos se denominan habitualmente 0 y 1, lo que coincide cómodamente con la arquitectura informática.

Un CRC se denomina CRC de n bits cuando su valor de comprobación tiene una longitud de n bits. Para un n dado , son posibles múltiples CRC, cada uno con un polinomio diferente. Un polinomio de este tipo tiene el grado más alto n , lo que significa que tiene n + 1 términos. En otras palabras, el polinomio tiene una longitud de n + 1 ; su codificación requiere n + 1 bits. Tenga en cuenta que la mayoría de las especificaciones de polinomios omiten el MSb o el LSb , ya que siempre son 1. El CRC y el polinomio asociado suelen tener un nombre de la forma CRC- n -XXX como en la tabla siguiente.

El sistema de detección de errores más simple, el bit de paridad , es de hecho un CRC de 1 bit: utiliza el polinomio generador  x + 1 (dos términos), ^[5] y tiene el nombre CRC-1.

Un dispositivo compatible con CRC calcula una secuencia binaria corta y de longitud fija, conocida como valor de verificación o CRC , para cada bloque de datos que se enviará o almacenará y la agrega a los datos, formando una palabra de código .

Cuando se recibe o lee una palabra de código, el dispositivo compara su valor de verificación con uno recién calculado a partir del bloque de datos o, equivalentemente, realiza una CRC en toda la palabra de código y compara el valor de verificación resultante con una constante residual esperada .

Si los valores CRC no coinciden, entonces el bloque contiene un error de datos.

El dispositivo puede tomar medidas correctivas, como volver a leer el bloque o solicitar que se envíe nuevamente. De lo contrario, se supone que los datos están libres de errores (aunque, con una pequeña probabilidad, pueden contener errores no detectados; esto es inherente a la naturaleza de la verificación de errores). ^[6]

Los CRC están diseñados específicamente para brindar protección contra tipos comunes de errores en los canales de comunicación, donde pueden brindar una garantía rápida y razonable de la integridad de los mensajes entregados. Sin embargo, no son adecuados para brindar protección contra la alteración intencional de datos.

En primer lugar, como no hay autenticación, un atacante puede editar un mensaje y volver a calcular el CRC sin que se detecte la sustitución. Cuando se almacenan junto con los datos, los CRC y las funciones hash criptográficas por sí solos no protegen contra la modificación intencional de los datos. Cualquier aplicación que requiera protección contra tales ataques debe utilizar mecanismos de autenticación criptográfica, como códigos de autenticación de mensajes o firmas digitales (que comúnmente se basan en funciones hash criptográficas ).

En segundo lugar, a diferencia de las funciones hash criptográficas, CRC es una función fácilmente reversible, lo que la hace inadecuada para su uso en firmas digitales. ^[7]

En tercer lugar, CRC satisface una relación similar a la de una función lineal (o más exactamente, una función afín ): ^[8]

${\displaystyle \nombreoperador {CRC} (x\omás y)=\nombreoperador {CRC} (x)\omás \nombreoperador {CRC} (y)\omás c}$

donde depende de la longitud de y . Esto también se puede expresar de la siguiente manera, donde , y tienen la misma longitud${\estilo de visualización c}$${\estilo de visualización x}$${\estilo de visualización y}$${\estilo de visualización x}$${\estilo de visualización y}$${\estilo de visualización z}$

${\displaystyle \operatorname {CRC} (x\oplus y\oplus z)=\operatorname {CRC} (x)\oplus \operatorname {CRC} (y)\oplus \operatorname {CRC} (z);}$

Como resultado, incluso si el CRC está cifrado con un cifrado de flujo que utiliza XOR como su operación de combinación (o modo de cifrado de bloque que lo convierte efectivamente en un cifrado de flujo, como OFB o CFB), tanto el mensaje como el CRC asociado pueden manipularse sin conocimiento de la clave de cifrado; este fue uno de los fallos de diseño bien conocidos del protocolo Wired Equivalent Privacy (WEP). ^[9]

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (July 2016) (Learn how and when to remove this message)

Para calcular un CRC binario de n bits, alinee los bits que representan la entrada en una fila y posicione el patrón de ( n + 1 ) bits que representa el divisor del CRC (llamado " polinomio ") debajo del extremo izquierdo de la fila.

En este ejemplo, codificaremos 14 bits de mensaje con un CRC de 3 bits, con un polinomio x ³ + x + 1 . El polinomio se escribe en binario como coeficientes; un polinomio de tercer grado tiene 4 coeficientes ( 1 x ³ + 0 x ² + 1 x + 1 ). En este caso, los coeficientes son 1, 0, 1 y 1. El resultado del cálculo tiene una longitud de 3 bits, por lo que se denomina CRC de 3 bits. Sin embargo, se necesitan 4 bits para indicar explícitamente el polinomio.

Comience con el mensaje a codificar:

11010011101100

Primero se rellena con ceros correspondientes a la longitud de bits n del CRC. Esto se hace para que la palabra de código resultante esté en forma sistemática . Aquí está el primer cálculo para calcular un CRC de 3 bits:

11010011101100 000 <--- entrada derecha rellenada con 3 bits1011 <--- divisor (4 bits) = x³ + x + 1------------------01100011101100 000 <--- resultado

El algoritmo actúa sobre los bits directamente sobre el divisor en cada paso. El resultado de esa iteración es la operación XOR bit a bit del divisor polinómico con los bits que están sobre él. Los bits que no están sobre el divisor simplemente se copian directamente debajo para ese paso. Luego, el divisor se desplaza hacia la derecha para alinearse con el bit restante más alto en la entrada, y el proceso se repite hasta que el divisor llega al extremo derecho de la fila de entrada. Aquí está el cálculo completo:

11010011101100 000 <--- entrada derecha rellenada con 3 bits1011 <--- divisor01100011101100 000 <--- resultado (tenga en cuenta que los primeros cuatro bits son el XOR con el divisor debajo, el resto de los bits no cambian) 1011 <--- divisor ...00111011101100 000 101100010111101100 000 101100000001101100 000 <--- tenga en cuenta que el divisor se mueve para alinearse con el siguiente 1 en el dividendo (ya que el cociente para ese paso era cero) 1011 (en otras palabras, no necesariamente se mueve un bit por iteración)00000000110100 000 101100000000011000 000 101100000000001110 000 101100000000000101 000 101 1-----------------00000000000000 100 <--- resto (3 bits). El algoritmo de división se detiene aquí porque el dividendo es igual a cero.

Dado que el bit divisor más a la izquierda puso a cero todos los bits de entrada que tocó, cuando este proceso termina, los únicos bits en la fila de entrada que pueden ser distintos de cero son los n bits en el extremo derecho de la fila. Estos n bits son el resto del paso de división y también serán el valor de la función CRC (a menos que la especificación CRC elegida requiera algún posprocesamiento).

La validez de un mensaje recibido se puede verificar fácilmente realizando nuevamente el cálculo anterior, esta vez con el valor de verificación agregado en lugar de ceros. El resto debe ser igual a cero si no hay errores detectables.

11010011101100 100 <--- entrada con valor de verificación1011 <--- divisor01100011101100 100 <--- resultado 1011 <--- divisor ...00111011101100 100......00000000001110 100 101100000000000101 100 101 1------------------00000000000000 000 <--- resto

El siguiente código Python describe una función que devolverá el resto del CRC inicial para una entrada y un polinomio elegidos, con 1 o 0 como relleno inicial. Tenga en cuenta que este código funciona con entradas de cadena en lugar de números sin formato:

def  crc_remainder ( entrada_bitstring ,  polinomio_bitstring ,  relleno_inicial ): """Calcula el resto de CRC de una cadena de bits utilizando un polinomio elegido.  relleno_inicial debe ser '1' o '0'.  """ cadena_bitstring_polinomio = cadena_bitstring_polinomio . lstrip ( '0' ) len_input = len ( entrada_bitstring ) relleno_inicial = ( len ( polinomio_bitstring ) - 1 ) * relleno_inicial matriz_rellenada_entrada = lista ( entrada_bitstring + relleno_inicial ) mientras '1' en matriz_rellenada_entrada [: len_input ]: cur_shift = matriz_rellenada_entrada . índice ( '1' ) para i en rango ( len ( cadena_de_bits_polinomiales )): matriz_rellenada_de_entrada [ cur_shift + i ] \ = str ( int ( cadena_de_bits_polinomiales [ i ] != matriz_rellenada_de_entrada [ cur_shift + i ])) devolver '' . join ( matriz_rellenada_de_entrada )[ len_input :]                                        def  crc_check ( entrada_bitstring ,  polinomio_bitstring ,  valor_comprobación ): """Calcula la comprobación CRC de una cadena de bits utilizando un polinomio elegido.""" polinomio_bitstring = polinomio_bitstring.lstrip ( ' 0 ' ) len_input = len ( entrada_bitstring ) relleno_inicial = valor_comprobación matriz_acolchada_entrada = lista ( entrada_bitstring + relleno_inicial ) mientras '1' en matriz_acolchada_entrada [: len_input ]: cur_shift = matriz_acolchada_entrada . índice ( '1' ) para i en rango ( len ( cadena_de_bits_polinomiales )): matriz_rellenada_de_entrada [ cur_shift + i ] \ = str ( int ( cadena_de_bits_polinomiales [ i ] != matriz_rellenada_de_entrada [ cur_shift + i ])) return ( '1' no está en '' . join ( matriz_rellenada_de_entrada )[ len_input :])                                       

>>> crc_remainder ( '11010011101100' ,  '1011' ,  '0' ) '100' >>> crc_check ( '11010011101100' ,  '1011' ,  '100' ) Verdadero

This section needs additional citations for verification. Please help improve this article by adding citations to reliable sources in this section. Unsourced material may be challenged and removed. (July 2016) (Learn how and when to remove this message)

El análisis matemático de este proceso similar a una división revela cómo seleccionar un divisor que garantice buenas propiedades de detección de errores. En este análisis, los dígitos de las cadenas de bits se toman como los coeficientes de un polinomio en alguna variable x —coeficientes que son elementos del cuerpo finito GF(2) (los números enteros módulo 2, es decir, un cero o un uno), en lugar de números más familiares. El conjunto de polinomios binarios es un anillo matemático .

La selección del polinomio generador es la parte más importante de la implementación del algoritmo CRC. El polinomio debe elegirse para maximizar las capacidades de detección de errores y minimizar las probabilidades generales de colisión.

El atributo más importante del polinomio es su longitud (mayor grado (exponente) +1 de cualquier término del polinomio), debido a su influencia directa en la longitud del valor de verificación calculado.

Las longitudes polinomiales más utilizadas son 9 bits (CRC-8), 17 bits (CRC-16), 33 bits (CRC-32) y 65 bits (CRC-64). ^[5]

Un CRC se denomina CRC de n bits cuando su valor de comprobación es de n bits. Para un valor n dado , son posibles múltiples CRC, cada uno con un polinomio diferente. Un polinomio de este tipo tiene el grado más alto n y, por lo tanto, n + 1 términos (el polinomio tiene una longitud de n + 1 ). El resto tiene una longitud n . El CRC tiene un nombre de la forma CRC- n -XXX.

El diseño del polinomio CRC depende de la longitud total máxima del bloque a proteger (datos + bits CRC), las características de protección contra errores deseadas y el tipo de recursos para implementar el CRC, así como el rendimiento deseado. Un error común es pensar que los "mejores" polinomios CRC se derivan de polinomios irreducibles o de polinomios irreducibles multiplicados por el factor  1 + x , lo que añade al código la capacidad de detectar todos los errores que afecten a un número impar de bits. ^[10] En realidad, todos los factores descritos anteriormente deberían entrar en la selección del polinomio y pueden conducir a un polinomio reducible. Sin embargo, la elección de un polinomio reducible dará como resultado una cierta proporción de errores omitidos, debido a que el anillo de cocientes tiene divisores de cero .

La ventaja de elegir un polinomio primitivo como generador para un código CRC es que el código resultante tiene una longitud de bloque total máxima en el sentido de que todos los errores de 1 bit dentro de esa longitud de bloque tienen diferentes residuos (también llamados síndromes ) y, por lo tanto, dado que el residuo es una función lineal del bloque, el código puede detectar todos los errores de 2 bits dentro de esa longitud de bloque. Si es el grado del polinomio generador primitivo, entonces la longitud de bloque total máxima es , y el código asociado puede detectar cualquier error de un solo bit o de dos bits. ^[11] Podemos mejorar esta situación. Si usamos el polinomio generador , donde es un polinomio primitivo de grado , entonces la longitud de bloque total máxima es , y el código puede detectar errores simples, dobles, triples y cualquier número impar de errores.${\displaystyle r}$${\displaystyle 2^{r}-1}$${\displaystyle g(x)=p(x)(1+x)}$${\displaystyle p}$${\displaystyle r-1}$${\displaystyle 2^{r-1}-1}$

Se puede elegir entonces un polinomio que admita otras factorizaciones para equilibrar la longitud de bloque total máxima con una potencia de detección de errores deseada. Los códigos BCH son una clase poderosa de tales polinomios. Engloban los dos ejemplos anteriores. Independientemente de las propiedades de reducibilidad de un polinomio generador de grado  r , si incluye el término "+1", el código podrá detectar patrones de error que están confinados a una ventana de r bits contiguos. Estos patrones se denominan "ráfagas de error".${\displaystyle g(x)}$

El concepto del CRC como código de detección de errores se complica cuando un implementador o un comité de normas lo utiliza para diseñar un sistema práctico. A continuación se enumeran algunas de las complicaciones:

• A veces, una implementación antepone un patrón de bits fijo al flujo de bits que se va a verificar. Esto resulta útil cuando los errores de sincronización pueden insertar bits 0 delante de un mensaje, una alteración que, de lo contrario, dejaría el valor de verificación sin cambios.
• Generalmente, pero no siempre, una implementación añade n bits 0 ( siendo n el tamaño del CRC) al flujo de bits que se va a comprobar antes de que se produzca la división polinómica. Dicha adición se demuestra explícitamente en el artículo Cálculo del CRC . Esto tiene la ventaja de que el resto del flujo de bits original con el valor de comprobación añadido es exactamente cero, por lo que el CRC se puede comprobar simplemente realizando la división polinómica en el flujo de bits recibido y comparando el resto con cero. Debido a las propiedades asociativas y conmutativas de la operación o exclusiva, las implementaciones prácticas controladas por tablas pueden obtener un resultado numéricamente equivalente a la adición de ceros sin añadir explícitamente ningún cero, utilizando un algoritmo equivalente ^[10] más rápido que combina el flujo de bits del mensaje con el flujo que se desplaza fuera del registro CRC.
• A veces, una implementación realiza una operación OR exclusiva con un patrón de bits fijo en el resto de la división polinomial.
• Orden de bits: algunos esquemas consideran que el bit de orden inferior de cada byte es el "primero", que luego, durante la división polinómica, significa el "más a la izquierda", lo que es contrario a nuestra comprensión habitual de "orden inferior". Esta convención tiene sentido cuando las transmisiones del puerto serie se verifican mediante CRC en el hardware, porque algunas convenciones de transmisión del puerto serie generalizadas transmiten los bytes con el bit menos significativo primero.
• Orden de bytes : con los CRC de varios bytes, puede haber confusión sobre si el byte transmitido primero (o almacenado en el byte de memoria con la dirección más baja) es el byte menos significativo (LSB) o el byte más significativo (MSB). Por ejemplo, algunos esquemas de CRC de 16 bits intercambian los bytes del valor de verificación.
• Omisión del bit de orden superior del polinomio divisor: dado que el bit de orden superior siempre es 1, y dado que un CRC de n bits debe definirse mediante un divisor de ( n + 1 ) bits que desborda un registro de n bits , algunos escritores suponen que no es necesario mencionar el bit de orden superior del divisor.
• Omisión del bit de orden inferior del polinomio divisor: dado que el bit de orden inferior siempre es 1, autores como Philip Koopman representan polinomios con su bit de orden superior intacto, pero sin el bit de orden inferior (el término o 1). Esta convención codifica el polinomio completo con su grado en un entero.${\displaystyle x^{0}}$

Estas complicaciones implican que existen tres formas comunes de expresar un polinomio como un entero: las dos primeras, que son imágenes especulares en binario, son las constantes que se encuentran en el código; la tercera es el número que se encuentra en los artículos de Koopman. En cada caso, se omite un término. Por lo tanto, el polinomio puede transcribirse como:${\displaystyle x^{4}+x+1}$

• 0x3 = 0b0011, que representa (código MSB-first)${\displaystyle x^{4}+(0x^{3}+0x^{2}+1x^{1}+1x^{0})}$
• 0xC = 0b1100, que representa (código LSB primero)${\displaystyle (1x^{0}+1x^{1}+0x^{2}+0x^{3})+x^{4}}$
• 0x9 = 0b1001, que representa (notación Koopman)${\displaystyle (1x^{4}+0x^{3}+0x^{2}+1x^{1})+x^{0}}$

En la siguiente tabla se muestran como:

Los CRC en protocolos propietarios se pueden ofuscar mediante el uso de un valor inicial no trivial y un XOR final, pero estas técnicas no agregan fuerza criptográfica al algoritmo y se pueden aplicar ingeniería inversa utilizando métodos sencillos. ^[12]

Se han incorporado numerosas variedades de comprobaciones de redundancia cíclica a las normas técnicas . De ninguna manera un algoritmo, o uno de cada grado, se adapta a todos los propósitos; Koopman y Chakravarty recomiendan seleccionar un polinomio según los requisitos de la aplicación y la distribución esperada de longitudes de mensajes. ^[13] La cantidad de CRC distintos en uso ha confundido a los desarrolladores, una situación que los autores han tratado de abordar. ^[10] Hay tres polinomios informados para CRC-12, ^[13] veintidós definiciones conflictivas de CRC-16 y siete de CRC-32. ^[14]

Los polinomios que se aplican habitualmente no son los más eficientes posibles. Desde 1993, Koopman, Castagnoli y otros han estudiado el espacio de polinomios de entre 3 y 64 bits de tamaño, ^{[13] [15] [16] [17]} encontrando ejemplos que tienen un rendimiento mucho mejor (en términos de distancia de Hamming para un tamaño de mensaje dado) que los polinomios de protocolos anteriores, y publicando los mejores de ellos con el objetivo de mejorar la capacidad de detección de errores de futuros estándares. ^[16] En particular, iSCSI y SCTP han adoptado uno de los hallazgos de esta investigación, el polinomio CRC-32C (Castagnoli).

El diseño del polinomio de 32 bits más comúnmente utilizado por los organismos de normalización, CRC-32-IEEE, fue el resultado de un esfuerzo conjunto para el Laboratorio de Roma y la División de Sistemas Electrónicos de la Fuerza Aérea por Joseph Hammond, James Brown y Shyan-Shiang Liu del Instituto de Tecnología de Georgia y Kenneth Brayer de la Corporación Mitre . Las primeras apariciones conocidas del polinomio de 32 bits fueron en sus publicaciones de 1975: Informe técnico 2956 de Brayer para Mitre, publicado en enero y lanzado para su difusión pública a través de DTIC en agosto, ^[18] y el informe de Hammond, Brown y Liu para el Laboratorio de Roma, publicado en mayo. ^[19] Ambos informes contenían contribuciones del otro equipo. Durante diciembre de 1975, Brayer y Hammond presentaron su trabajo en un artículo en la Conferencia Nacional de Telecomunicaciones IEEE: el polinomio IEEE CRC-32 es el polinomio generador de un código Hamming y fue seleccionado por su rendimiento de detección de errores. ^[20] Aun así, el polinomio Castagnoli CRC-32C utilizado en iSCSI o SCTP iguala su rendimiento en mensajes de 58 bits a 131 kbits, y lo supera en varios rangos de tamaño, incluidos los dos tamaños más comunes de paquetes de Internet. ^[16] El estándar ITU-T G.hn también utiliza CRC-32C para detectar errores en la carga útil (aunque utiliza CRC-16-CCITT para los encabezados PHY ).

El cálculo CRC-32C se implementa en hardware como una operación ( CRC32) del conjunto de instrucciones SSE4.2 , introducido por primera vez en la microarquitectura Nehalem de los procesadores Intel . La arquitectura ARM AArch64 también proporciona aceleración de hardware para operaciones CRC-32 y CRC-32C.

La tabla siguiente enumera solo los polinomios de los diversos algoritmos en uso. Las variaciones de un protocolo particular pueden imponer una ordenación de bits previa, posterior y inversa como se describió anteriormente. Por ejemplo, el CRC32 utilizado en Gzip y Bzip2 utiliza el mismo polinomio, pero Gzip emplea una ordenación de bits inversa, mientras que Bzip2 no. ^[14] Tenga en cuenta que los polinomios de paridad par en GF(2) con grado mayor que 1 nunca son primitivos. Los polinomios de paridad par marcados como primitivos en esta tabla representan un polinomio primitivo multiplicado por . El bit más significativo de un polinomio siempre es 1 y no se muestra en las representaciones hexadecimales.${\displaystyle \left(x+1\right)}$

Nombre	Usos	Representaciones polinómicas				Paridad [21]	Primitivo [22]	Máximo número de bits de carga útil por distancia de Hamming [23] [16] [22]
		Normal	Invertida	Recíproca	Recíproco invertido			≥ 16	15	14	13	12	11	10	9	8	7	6	5	4	3	2 [24]
CRC-1	La mayoría del hardware; también conocido como bit de paridad	0x1	0x1	0x1	0x1	incluso
		${\displaystyle x+1}$
CRC-3- GSM	redes móviles [25]	0x3	0x6	0x5	0x5	extraño	Sí [26]	–	–	–	–	–	–	–	–	–	–	–	–	–	4	∞
		${\displaystyle x^{3}+x+1}$
CRC-4-UIT	UIT-T G.704, pág. 12	0x3	0xC	0x9	0x9	extraño
		${\displaystyle x^{4}+x+1}$
CRC-5-EPC	RFID de segunda generación [27]	0x09	0x12	0x05	0x14	extraño
		${\displaystyle x^{5}+x^{3}+1}$
CRC-5-UIT	UIT-T G.704, pág. 9	0x15	0x15	0x0B	0x1A	incluso
		${\displaystyle x^{5}+x^{4}+x^{2}+1}$
CRC-5-USB	Paquetes de tokens USB	0x05	0x14	0x09	0x12	extraño
		${\displaystyle x^{5}+x^{2}+1}$
CRC-6- CDMA2000 -A	redes móviles [28]	0x27	0x39	0x33	0x33	extraño
CRC-6- CDMA2000 -B	redes móviles [28]	0x07	0x38	0x31	0x23	incluso
CRC-6-DARC	Canal de radio de datos [29]	0x19	0x26	0x0D	0x2C	incluso
CRC-6- GSM	redes móviles [25]	0x2F	0x3D	0x3B	0x37	incluso	Sí [30]	–	–	–	–	–	–	–	–	–	–	1	1	25	25	∞
		${\displaystyle x^{6}+x^{5}+x^{3}+x^{2}+x+1}$
CRC-6-UIT	UIT-T G.704, pág. 3	0x03	0x30	0x21	0x21	extraño
		${\displaystyle x^{6}+x+1}$
CRC-7	sistemas de telecomunicaciones, ITU-T G.707, ITU-T G.832, MMC , SD	0x09	0x48	0x11	0x44	extraño
		${\displaystyle x^{7}+x^{3}+1}$
CRC-7-MVB	Red de comunicación ferroviaria , IEC 60870-5 [31]	0x65	0x53	0x27	0x72	extraño
CRC-8	DVB-S2 [32]	0xD5	0xAB	0x57	0xEA [13]	incluso	No [33]	–	–	–	–	–	–	–	–	–	–	2	2	85	85	∞
		${\displaystyle x^{8}+x^{7}+x^{6}+x^{4}+x^{2}+1}$
CRC-8- AUTOSAR	Integración automotriz, [34] OpenSafety [35]	0x2F	0xF4	0xE9	0x97 [13]	incluso	Sí [33]	–	–	–	–	–	–	–	–	–	–	3	3	119	119	∞
		${\displaystyle x^{8}+x^{5}+x^{3}+x^{2}+x+1}$
CRC-8- Bluetooth	Conectividad inalámbrica [36]	0xA7	0xE5	0xCB	0xD3	incluso
		${\displaystyle x^{8}+x^{7}+x^{5}+x^{2}+x+1}$
CRC-8- CCITT	UIT-T I.432.1 (02/99); HEC ATM , HEC ISDN y delimitación de celdas, PEC SMBus	0x07	0xE0	0xC1	0x83	incluso
		${\displaystyle x^{8}+x^{2}+x+1}$
CRC-8- Dallas / Maxim	Bus de 1 cable [37]	0x31	0x8C	0x19	0x98	incluso
		${\displaystyle x^{8}+x^{5}+x^{4}+1}$
CRC-8-DARC	Canal de radio de datos [29]	0x39	0x9C	0x39	0x9C	extraño
		${\displaystyle x^{8}+x^{5}+x^{4}+x^{3}+1}$
CRC-8- GSM -B	redes móviles [25]	0x49	0x92	0x25	0xA4	incluso
		${\displaystyle x^{8}+x^{6}+x^{3}+1}$
CRC-8- SAE J1850	AES3 ; OBD2	0x1D	0xB8	0x71	0x8E	extraño
		${\displaystyle x^{8}+x^{4}+x^{3}+x^{2}+1}$
CRC-8-WCDMA	redes móviles [28] [38]	0x9B	0xD9	0xB3	0xCD [13]	incluso
		${\displaystyle x^{8}+x^{7}+x^{4}+x^{3}+x+1}$
CRC-10	ATM; UIT-T I.610	0x233	0x331	0x263	0x319	incluso
		${\displaystyle x^{10}+x^{9}+x^{5}+x^{4}+x+1}$
CRC-10- CDMA2000	redes móviles [28]	0x3D9	0x26F	0x0DF	0x3EC	incluso
CRC-10- GSM	redes móviles [25]	0x175	0x2BA	0x175	0x2BA	extraño
CRC-11	Rayo flexible [39]	0x385	0x50E	0x21D	0x5C2	incluso
		${\displaystyle x^{11}+x^{9}+x^{8}+x^{7}+x^{2}+1}$
CRC-12	sistemas de telecomunicaciones [40] [41]	0x80F	0xF01	0xE03	0xC07 [13]	incluso
		${\displaystyle x^{12}+x^{11}+x^{3}+x^{2}+x+1}$
CRC-12- CDMA2000	redes móviles [28]	0xF13	0xC8F	0x91F	0xF89	incluso
CRC-12- GSM	redes móviles [25]	0xD31	0x8CB	0x197	0xE98	extraño
CRC-13-BBC	Señal horaria, Teleconmutador de radio [42] [43]	0x1CF5	0x15E7	0x0BCF	0x1E7A	incluso
		${\displaystyle x^{13}+x^{12}+x^{11}+x^{10}+x^{7}+x^{6}+x^{5}+x^{4}+x^{2}+1}$
CRC-14-DARC	Canal de radio de datos [29]	0x0805	0x2804	0x1009	0x2402	incluso
CRC-14- GSM	redes móviles [25]	0x202D	0x2D01	0x1A03	0x3016	incluso
CRC-15- PUEDE		0xC599 [44] [45]	0x4CD1	0x19A3	0x62CC	incluso
		${\displaystyle x^{15}+x^{14}+x^{10}+x^{8}+x^{7}+x^{4}+x^{3}+1}$
CRC-15- MPT1327	[46]	0x6815	0x540B	0x2817	0x740A	extraño
CRC-16-Chakravarty	Óptimo para cargas útiles ≤64 bits [31]	0x2F15	0xA8F4	0x51E9	0x978A	extraño
CRC-16- ARINC	Aplicaciones de ACARS [47]	0xA02B	0xD405	0xA80B	0xD015	extraño
CRC-16-CCITT	X.25 , V.41 , HDLC FCS , XMODEM , Bluetooth , PACTOR , SD , DigRF y muchos otros; conocidos como CRC-CCITT	0x1021	0x8408	0x811	0x8810 [13]	incluso
		${\displaystyle x^{16}+x^{12}+x^{5}+1}$
CRC-16- CDMA2000	redes móviles [28]	0xC867	0xE613	0xCC27	0xE433	extraño
CRC-16- DECT	teléfonos inalámbricos [48]	0x0589	0x91A0	0x2341	0x82C4	incluso
		${\displaystyle x^{16}+x^{10}+x^{8}+x^{7}+x^{3}+1}$
CRC-16- T10 - DIF	Diferencia SCSI	0x8BB7 [49]	0xEDD1	0xDBA3	0xC5DB	extraño
		${\displaystyle x^{16}+x^{15}+x^{11}+x^{9}+x^{8}+x^{7}+x^{5}+x^{4}+x^{2}+x+1}$
CRC-16- DNP	DNP, IEC 870 , bus M	0x3D65	0xA6BC	0x4D79	0x9EB2	incluso
		${\displaystyle x^{16}+x^{13}+x^{12}+x^{11}+x^{10}+x^{8}+x^{6}+x^{5}+x^{2}+1}$
CRC-16- IBM	Bisync , Modbus , USB , ANSI X3.28, SIA DC-07, muchos otros; también conocidos como CRC-16 y CRC-16-ANSI	0x8005	0xA001	0x4003	0xC002	incluso
		${\displaystyle x^{16}+x^{15}+x^{2}+1}$
CRC-16- Seguridad abierta -A	bus de campo de seguridad [35]	0x5935	0xAC9A	0x5935	0xAC9A [13]	extraño
CRC-16- Seguridad abierta -B	bus de campo de seguridad [35]	0x755B	0xDAAE	0xB55D	0xBAAD [13]	extraño
CRC-16- Profibus	redes de bus de campo [50]	0x1DCF	0xF3B8	0xE771	0x8EE7	extraño
Fletcher-16	Se utiliza en las sumas de comprobación Adler-32 A y B	A menudo se confunde con un CRC, pero en realidad es una suma de comprobación; consulte la suma de comprobación de Fletcher
CRC-17-CAN	Puede ser FD [51]	0x1685B	0x1B42D	0x1685B	0x1B42D	incluso
CRC-21-CAN	Puede ser FD [51]	0x102899	0x132281	0x064503	0x18144C	incluso
CRC-24	Rayo flexible [39]	0x5D6DCB	0xD3B6BA	0xA76D75	0xAEB6E5	incluso
		${\displaystyle 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}$
CRC-24- Radix-64	OpenPGP , RTCM 104v3	0x864CFB	0xDF3261	0xBE64C3	0xC3267D	incluso
		${\displaystyle 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}$
CRC-24- WCDMA	Se utiliza en OS-9 RTOS . Residuo = 0x800FE3. [52]	0x800063	0xC60001	0x8C0003	0xC00031	incluso	Sí [53]	–	–	–	–	–	–	–	–	–	–	4	4	8388583	8388583	∞
		${\displaystyle x^{24}+x^{23}+x^{6}+x^{5}+x+1}$
CRC-30	CDMA	0x2030B9C7	0x38E74301	0x31CE8603	0x30185CE3	incluso
		${\displaystyle 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}$
CRC-32	ISO 3309 ( HDLC ), ANSI X3.66 ( ADCCP ), FIPS PUB 71, FED-STD-1003, ITU-T V.42 , ISO/IEC/IEEE 802-3 ( Ethernet ), SATA , MPEG-2 , PKZIP , Gzip , Bzip2 , POSIX cksum , [54] PNG , [55] ZMODEM y muchos otros.	0x04C11DB7	0xEDB88320	0xDB710641	0x82608EDB [16]	extraño	Sí	–	10	–	–	12	21	34	57	91	171	268	2974	91607	4294967263	∞
		${\displaystyle 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}$
CRC-32C (Castagnoli)	iSCSI , SCTP , carga útil G.hn , SSE4.2 , Btrfs , ext4 , Ceph	0x1EDC6F41	0x82F63B78	0x05EC76F1	0x8F6E37A0 [16]	incluso	Sí	6	–	8	–	20	–	47	–	177	–	5243	–	2147483615	–	∞
		${\displaystyle 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}$
CRC-32K (Koopman {1,3,28})	Excelente con longitud de trama Ethernet, rendimiento deficiente con archivos largos [ cita requerida ]	0x741B8CD7	0xEB31D82E	0xD663B05D	0xBA0DC66B [16]	incluso	No	2	–	4	–	16	–	18	–	152	–	16360	–	114663	–	∞
		${\displaystyle 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}$
CRC-32K 2 (Koopman {1,1,30})	Excelente con longitud de trama Ethernet, rendimiento deficiente con archivos largos [ cita requerida ]	0x32583499	0x992C1A4C	0x32583499	0x992C1A4C [16]	incluso	No	–	–	3	–	16	–	26	–	134	–	32738	–	65506	–	∞
CRC-32Q	aviación; AIXM [56]	0x814141AB	0xD5828281	0xAB050503	0xC0A0A0D5	incluso
		${\displaystyle x^{32}+x^{31}+x^{24}+x^{22}+x^{16}+x^{14}+x^{8}+x^{7}+x^{5}+x^{3}+x+1}$
Adler-32		A menudo se confunde con un CRC, pero en realidad es una suma de comprobación; consulte Adler-32
CRC-40- GSM	Canal de control GSM [57] [58] [59]	0x0004820009	0x9000412000	0x2000824001	0x8002410004	incluso
		${\displaystyle x^{40}+x^{26}+x^{23}+x^{17}+x^{3}+1=(x^{23}+1)(x^{17}+x^{3}+1)}$
CRC-64- ECMA	ECMA-182 pág. 51, Utilidades XZ	0x42F0E1EBA9EA3693	0xC96C5795D7870F42	0x92D8AF2BAF0E1E85	0xA17870F5D4F51B49	incluso
		${\displaystyle 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}+}$ ${\displaystyle 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}$
CRC-64-ISO	ISO 3309 ( HDLC ), Swiss-Prot / TrEMBL ; considerado débil para hash [60]	0x000000000000001B	0xD800000000000000	0xB000000000000001	0x8000000000000000D	extraño
		${\displaystyle x^{64}+x^{4}+x^{3}+x+1}$

• Implementación de CRC32 en GNU Radio hasta la versión 3.6.1 (aproximadamente 2012)
• Código de clase C para el cálculo de suma de comprobación CRC con muchos CRC diferentes para elegir

• Catálogo de algoritmos CRC parametrizados
• Zoológico de polinomios CRC

• Suma de comprobación
• Cálculo de comprobaciones de redundancia cíclica
• Seguridad de la información
• Lista de algoritmos de suma de comprobación
• Lista de funciones hash
• LRC
• Matemáticas de comprobaciones de redundancia cíclica
• Verificación de archivos sencilla

• ISO/IEC 13239:2002: Tecnología de la información - Telecomunicaciones e intercambio de información entre sistemas - Procedimientos de control de enlace de datos de alto nivel (HDLC)
• Biblioteca Linux CRC32-Castagnoli