Verificación de redundancia cíclica

Tipo de función hash utilizada para detectar errores en el almacenamiento o transmisión de datos

Una verificación de redundancia cíclica ( CRC ) es un código de detección de errores que se usa comúnmente en redes digitales y dispositivos de almacenamiento para detectar cambios accidentales en los datos sin procesar. Los bloques de datos que ingresan a estos sistemas obtienen un valor de verificación breve adjunto, basado en el resto de una división polinómica de su contenido. En la recuperación, el cálculo se repite y, en caso de que los valores de verificación no coincidan, se pueden tomar medidas correctivas contra la corrupción de datos. Los CRC se pueden utilizar para la corrección de errores (ver filtros de bits ). ^[1]

Los CRC se denominan así porque el valor de verificación (verificación de datos) es una redundancia (expande el mensaje sin agregar información ) y el algoritmo se basa en códigos cíclicos . Los CRC son populares porque son simples de implementar en hardware binario , fáciles de analizar matemáticamente y particularmente buenos para detectar errores comunes causados ​​por el 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 usa ocasionalmente como función hash .

Introducción

Los CRC se basan en la teoría de los códigos de corrección de errores cíclicos . El uso de códigos cíclicos sistemáticos , que codifican mensajes agregando un valor de verificación de longitud fija, con el propósito de detectar errores en las redes de comunicación, fue propuesto por primera vez por W. Wesley Peterson en 1961. ^[2] Los códigos cíclicos no solo son simples de implementan, pero 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 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 una n-bit CRC aplicado a un bloque de datos de longitud arbitraria detectará cualquier ráfaga de error única que no supere los n bits, y la fracción de todas las ráfagas de error más largas que detectará es (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 un polinomio de división larga , que toma el mensaje como dividendo y en el que se descarta el cociente y el resto se convierte en el resultado. La advertencia importante es que los coeficientes polinomiales se calculan de acuerdo con la aritmética de un campo finito , por lo que la operación de suma siempre se puede realizar en paralelo a los bits (no hay acarreo entre dígitos).

En la práctica, todos los CRC de uso común emplean el campo de Galois , o más simplemente un campo finito, de dos elementos, GF (2) . Los dos elementos generalmente se denominan 0 y 1, que coinciden cómodamente con la arquitectura del ordenador.

A CRC se denomina n bits CRC cuando su valor de comprobación es n bits de longitud. Para un n dado , son posibles múltiples CRC, cada uno con un polinomio diferente. Dicho polinomio tiene el grado n más alto , 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 polinomiales descartan MSB o LSB , ya que siempre son 1. El CRC y el polinomio asociado generalmente tienen un nombre de la forma CRC- n -XXX como en la siguiente tabla .

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) y tiene el nombre CRC-1.

Aplicación

Un dispositivo habilitado para CRC calcula una secuencia binaria corta de longitud fija, conocida como el valor de verificación o CRC , para cada bloque de datos que se enviará o almacenará y lo agregará 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, de manera equivalente, realiza un CRC en toda la palabra de código y compara el valor de verificación resultante con una constante de residuo esperada .

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

El dispositivo puede tomar una acción correctiva, como releer 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). ^[3]

Integridad de datos

Los CRC están diseñados específicamente para proteger contra tipos comunes de errores en los canales de comunicación, donde pueden proporcionar una garantía rápida y razonable de la integridad de los mensajes entregados. Sin embargo, no son adecuados para proteger 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í mismas 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. ^[4]

En tercer lugar, CRC es una función lineal con una propiedad que ^[5]

${\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á encriptado con un cifrado de flujo que usa XOR como su operación de combinación (o modo de cifrado de bloque que efectivamente lo convierte en un cifrado de flujo, como OFB o CFB), tanto el mensaje como el CRC asociado se puede manipular sin conocimiento de la clave de cifrado; Este fue uno de los defectos de diseño más conocidos del protocolo Wired Equivalent Privacy (WEP). ^[6]

Computación

Esta sección no cita ninguna fuente . Por favor, ayuda a mejorar esta sección mediante la adición de citas de fuentes confiables . El material no obtenido puede ser cuestionado y eliminado . ( Julio de 2016 ) ( Obtenga información sobre cómo y cuándo eliminar este mensaje de plantilla )

Artículo principal: Cálculo de comprobaciones de redundancia cíclica

Para calcular un CRC binario de n bits, alinee los bits que representan la entrada en una fila y coloque 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, necesita 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 bit 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 encima del divisor en cada paso. El resultado de esa iteración es el XOR bit a bit del divisor polinomial con los bits encima. Los bits que no están por encima del divisor simplemente se copian directamente debajo para ese paso. Luego, el divisor se desplaza hacia la derecha para alinearse con el bit 1 restante más alto en la entrada, y el proceso se repite hasta que el divisor alcanza el 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 se modifican) 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í ya que el dividendo es igual a cero.

Dado que el bit divisor más a la izquierda puso a cero cada bit de entrada que tocó, cuando este proceso finaliza, 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 el cálculo anterior nuevamente, 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.

11010011101100100 <--- entrada con valor de verificación1011 <--- divisor01100011101100100 <--- resultado 1011 <--- divisor ...00111011101100 100......00000000001110 100 101100000000000101100 101 1------------------00000000000000 000 <--- resto

El siguiente código de Python describe una función que devolverá el resto de CRC inicial para una entrada y 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 ( input_bitstring ,  polynomial_bitstring ,  initial_filler ):  "" "Calcula el CRC restante de una cadena de bits usando un polinomio elegido.  initial_filler debe ser '1' o '0'.  " ""  polynomial_bitstring  =  polynomial_bitstring . lstrip ( '0' )  len_input  =  len ( input_bitstring )  initial_padding  =  ( len ( polynomial_bitstring )  -  1 )  *  initial_filler input_padded_array  =  lista ( input_bitstring  +  initial_padding )  while  '1'  en  input_padded_array [: len_input ]:  cur_shift  =  input_padded_array . index ( '1' )  para  i  en el  rango ( len ( polynomial_bitstring )):  input_padded_array [ cur_shift  +  i ] \ =  str ( int ( polynomial_bitstring [i ]  ! =  input_padded_array [ cur_shift  +  i ]))  return  '' . unirse ( input_padded_array ) [ len_input :]def  crc_check ( input_bitstring ,  polynomial_bitstring ,  check_value ):  "" "Calcula la verificación CRC de una cadena de bits usando un polinomio elegido." ""  polynomial_bitstring  =  polynomial_bitstring . lstrip ( '0' )  len_input  =  len ( input_bitstring )  initial_padding  =  check_value  input_padded_array  =  list ( input_bitstring  +  initial_padding )  while  '1'  en  input_padded_array [:len_input ]:  cur_shift  =  input_padded_array . índice ( '1' )  para  i  en el  rango ( len ( polynomial_bitstring )):  input_padded_array [ cur_shift  +  i ] \ =  str ( int ( polynomial_bitstring [ i ]  ! =  input_padded_array [ cur_shift  +  i )])  de retorno  ( '1'  no  en  '' .unirse ( input_padded_array ) [ len_input :])

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

Algoritmo CRC-32

Este es un algoritmo práctico para la variante CRC-32 de CRC. ^[7] El CRCTable es una memorización de un cálculo que debería repetirse para cada byte del mensaje ( Cálculo de comprobaciones de redundancia cíclica § Cálculo multibit ).

Función CRC32  de entrada: datos: Bytes  matriz de bytes //  Salida: crc32: UInt32  // 32 bits sin signo valor CRC32 
// Inicializar CRC32 a partir valor
crc32 ← 0xFFFFFFFF
 para cada byte de datos hacer nLookupIndex ← (crc32 xor byte) y 0xFF; crc32 ← (crc32 shr 8) xor CRCTable [nLookupIndex] // CRCTable es una matriz de 256 constantes de 32 bits 
// Finalice el valor CRC-32 invirtiendo todos los bitscrc32 ← crc32 xor 0xFFFFFFFFvolver crc32

Matemáticas

Esta sección no cita ninguna fuente . Por favor, ayuda a mejorar esta sección mediante la adición de citas de fuentes confiables . El material no obtenido puede ser cuestionado y eliminado . ( Julio de 2016 ) ( Obtenga información sobre cómo y cuándo eliminar este mensaje de plantilla )

Artículo principal: Matemáticas de comprobaciones de redundancia cíclica

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 campo 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 .

Diseñar polinomios

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 al tiempo que se minimizan las probabilidades generales de colisión.

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

Las longitudes de polinomio más utilizadas son:

• 9 bits (CRC-8)
• 17 bits (CRC-16)
• 33 bits (CRC-32)
• 65 bits (CRC-64)

A CRC se denomina n bits CRC cuando su valor de comprobación es n -bits. Para un n dado , son posibles múltiples CRC, cada uno con un polinomio diferente. Dicho polinomio tiene el grado n más alto 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 que los "mejores" polinomios CRC se derivan de polinomios irreducibles o polinomios irreducibles multiplicados por el factor  1 + x , lo que agrega al código la capacidad de detectar todos los errores que afectan a un número impar de bits. ^[8] 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, elegir un polinomio reducible resultará en una cierta proporción de errores perdidos, debido a que el anillo del cociente tienedivisores de cero .

La ventaja de elegir un polinomio primitivo como generador de 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 residuos diferentes (también llamados síndromes ) y, por tanto, desde El resto 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 máxima total del bloque es , y el código asociado es capaz de detectar cualquier error de bit simple o bit doble. ^[9] Podemos mejorar esta situación. Si usamos el polinomio generador , donde es un polinomio primitivo de grado${\displaystyle r}$${\displaystyle 2^{r}-1}$${\displaystyle g(x)=p(1+x)}$${\displaystyle p}$${\displaystyle r-1}$, entonces la longitud máxima del bloque total es , y el código es capaz de detectar errores simples, dobles, triples y cualquier número impar.${\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. Incluyen 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 se limitan a una ventana de r bits contiguos. Estos patrones se denominan "ráfagas de error".${\displaystyle g(x)}$

Especificación

El concepto de CRC como un código de detección de errores se complica cuando un implementador o comité de estándares lo usa para diseñar un sistema práctico. Estas son 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 es útil cuando los errores de reloj pueden insertar 0 bits delante de un mensaje, una alteración que de otro modo dejaría el valor de verificación sin cambios.
• Por lo general, pero no siempre, una implementación agrega n bits 0 ( siendo n el tamaño del CRC) al flujo de bits para verificarlo antes de que ocurra la división polinómica. Tal anexión se demuestra explícitamente en el artículo de Computación de CRC . Esto tiene la conveniencia de que el resto del flujo de bits original con el valor de verificación agregado es exactamente cero, por lo que el CRC se puede verificar simplemente realizando la división polinomial en el flujo de bits recibido y comparando el resto con cero. Debido a las propiedades asociativas y conmutativas de la operación exclusiva o, las implementaciones prácticas basadas en tablas pueden obtener un resultado numéricamente equivalente a agregar ceros sin agregar explícitamente ningún cero, utilizando un equivalente,^[8] algoritmo 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 OR exclusiva aplica un patrón de bits fijo al resto de la división polinomial.
• Orden de bits: algunos esquemas ven el bit de orden bajo de cada byte como "primero", que luego durante la división polinomial significa "más a la izquierda", lo cual es contrario a nuestra comprensión habitual de "orden bajo". Esta convención tiene sentido cuando las transmisiones de puerto serie se comprueban mediante CRC en el hardware, porque algunas convenciones generalizadas de transmisión de puerto serie transmiten bytes con el bit menos significativo primero.
• Orden de bytes : con CRC multibyte, 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 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 es siempre 1, y dado que un CRC de n bits debe estar definido por un divisor de ( n + 1 ) bits que desborda un registro de n bits , algunos escritores asumen que es innecesario 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 significan que hay tres formas comunes de expresar un polinomio como un número entero: las dos primeras, que son imágenes espejo en binario, son las constantes que se encuentran en el código; el tercero es el número que se encuentra en los artículos de Koopman. En cada caso, se omite un término. Entonces, el polinomio se puede transcribir como:${\displaystyle x^{4}+x+1}$

• 0x3 = 0b0011, que representa (primer código MSB)${\displaystyle x^{4}+(0x^{3}+0x^{2}+1x^{1}+1x^{0})}$
• 0xC = 0b1100, que representa (primer código LSB)${\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:

Ejemplos de representaciones CRC

Nombre	Normal	Invertido	Recíproco invertido
CRC-4	0x3	0xC	0x9

Ofuscación

Los CRC en protocolos propietarios pueden ofuscarse 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 pueden modificarse mediante ingeniería inversa utilizando métodos sencillos. ^[10]

Estándares y uso común

Se han incorporado numerosas variedades de comprobaciones de redundancia cíclica en 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 de acuerdo con los requisitos de la aplicación y la distribución esperada de la longitud de los mensajes. ^[11] El número de CRC distintos en uso ha confundido a los desarrolladores, una situación que los autores han tratado de abordar. ^[8] Hay tres polinomios reportados para CRC-12, ^[11] veintidós definiciones contradictorias de CRC-16 y siete de CRC-32. ^[12]

Los polinomios que se aplican comúnmente no son los más eficientes posibles. Desde 1993, Koopman, Castagnoli y otros han estudiado el espacio de polinomios entre 3 y 64 bits de tamaño, ^{[11] [13] [14] [15]} encontrando ejemplos que tienen un rendimiento mucho mejor (en términos de distancia de Hamming para un tamaño del mensaje) que los polinomios de protocolos anteriores, y publicando el mejor de ellos con el objetivo de mejorar la capacidad de detección de errores de los estándares futuros. ^[14] 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 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 Mitre Corporation . 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 difusión pública a través de DTIC en agosto, ^[16] y el informe de Hammond, Brown y Liu para Roma. Laboratorio, publicado en mayo. ^[17]Ambos informes contenían contribuciones del otro equipo. Durante diciembre de 1975, Brayer y Hammond presentaron su trabajo en un documento en la Conferencia Nacional de Telecomunicaciones de IEEE: el polinomio IEEE CRC-32 es el polinomio generador de un código de Hamming y fue seleccionado por su rendimiento de detección de errores. ^[18] Aun así, el polinomio Castagnoli CRC-32C usado en iSCSI o SCTP iguala su desempeño 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. ^[14] El estándar ITU-T G.hn también usa CRC-32C para detectar errores en la carga útil (aunque usa CRC-16-CCITT para encabezados PHY ).

CRC32C cálculo se implementa en hardware como una operación ( CRC32) de SSE4.2 conjunto de instrucciones, introducido por primera vez en Intel procesadores Nehalem microarquitectura. Las operaciones CRC32C también se definen en AArch64 .

Representaciones polinomiales de comprobaciones de redundancia cíclica

La siguiente tabla enumera solo los polinomios de los distintos algoritmos en uso. Las variaciones de un protocolo en particular pueden imponer preinversión, posinversión y ordenamiento de bits invertido como se describe anteriormente. Por ejemplo, el CRC32 usado en Gzip y Bzip2 usan el mismo polinomio, pero Gzip emplea orden de bits invertido, mientras que Bzip2 no lo hace. ^[12] Nótese que incluso los polinomios de paridad en GF (2) con un grado mayor que 1 nunca son primitivos. Incluso el polinomio de paridad marcado como primitivo en esta tabla representa un polinomio primitivo multiplicado por . Tenga en cuenta que el bit más significativo de un polinomio es siempre 1 y no se muestra en las representaciones hexadecimales.${\displaystyle \left(x+1\right)}$

Nombre	Usos	Representaciones polinomiales				Paridad [19]	Primitivo [20]	Bits máximos de carga útil por distancia de Hamming [21] [14] [20]
		Normal	Invertido	Recíproco	Recíproco invertido			≥ 16	15	14	13	12	11	10	9	8	7	6	5	4	3	2 [22]
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 [23]	0x3	0x6	0x5	0x5	impar	sí [24]	-	-	-	-	-	-	-	-	-	-	-	-	-	4	∞
		${\displaystyle x^{3}+x+1}$
CRC-4-ITU	UIT-T G.704 , pág. 12	0x3	0xC	0x9	0x9	impar
		${\displaystyle x^{4}+x+1}$
CRC-5-EPC	RFID de 2.a generación [25]	0x09	0x12	0x05	0x14	impar
		${\displaystyle x^{5}+x^{3}+1}$
CRC-5-ITU	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 token USB	0x05	0x14	0x09	0x12	impar
		${\displaystyle x^{5}+x^{2}+1}$
CRC-6- CDMA2000 -A	redes móviles [26]	0x27	0x39	0x33	0x33	impar
CRC-6- CDMA2000 -B	redes móviles [26]	0x07	0x38	0x31	0x23	incluso
CRC-6-DARC	Canal de radio de datos [27]	0x19	0x26	0x0D	0x2C	incluso
CRC-6- GSM	redes móviles [23]	0x2F	0x3D	0x3B	0x37	incluso	sí [28]	-	-	-	-	-	-	-	-	-	-	1	1	25	25	∞
		${\displaystyle x^{6}+x^{5}+x^{3}+x^{2}+x+1}$
CRC-6-ITU	UIT-T G.704 , pág. 3	0x03	0x30	0x21	0x21	impar
		${\displaystyle x^{6}+x+1}$
CRC-7	sistemas de telecomunicaciones, UIT-T G.707 , UIT-T G.832 , MMC , SD	0x09	0x48	0x11	0x44	impar
		${\displaystyle x^{7}+x^{3}+1}$
CRC-7-MVB	Red de comunicación de trenes , IEC 60870-5 [29]	0x65	0x53	0x27	0x72	impar
CRC-8	DVB-S2 [30]	0xD5	0xAB	0x57	0xEA [11]	incluso	no [31]	-	-	-	-	-	-	-	-	-	-	2	2	85	85	∞
		${\displaystyle x^{8}+x^{7}+x^{6}+x^{4}+x^{2}+1}$
CRC-8- AUTOSAR	integración automotriz, [32] OpenSafety [33]	0x2F	0xF4	0xE9	0x97 [11]	incluso	sí [31]	-	-	-	-	-	-	-	-	-	-	3	3	119	119	∞
		${\displaystyle x^{8}+x^{5}+x^{3}+x^{2}+x+1}$
CRC-8- Bluetooth	conectividad inalámbrica [34]	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) ; ATM HEC , ISDN HEC y delimitación de celda, SMBus PEC	0x07	0xE0	0xC1	0x83	incluso
		${\displaystyle x^{8}+x^{2}+x+1}$
CRC-8- Dallas / Maxim	Bus de 1 cable [35]	0x31	0x8C	0x19	0x98	incluso
		${\displaystyle x^{8}+x^{5}+x^{4}+1}$
CRC-8-DARC	Canal de radio de datos [27]	0x39	0x9C	0x39	0x9C	impar
		${\displaystyle x^{8}+x^{5}+x^{4}+x^{3}+1}$
CRC-8- GSM -B	redes móviles [23]	0x49	0x92	0x25	0xA4	incluso
		${\displaystyle x^{8}+x^{6}+x^{3}+1}$
CRC-8- SAE J1850	AES3 ; OBD	0x1D	0xB8	0x71	0x8E	impar
		${\displaystyle x^{8}+x^{4}+x^{3}+x^{2}+1}$
CRC-8- WCDMA	redes móviles [26] [36]	0x9B	0xD9	0xB3	0xCD [11]	incluso
		${\displaystyle x^{8}+x^{7}+x^{4}+x^{3}+x+1}$
CRC-10	CAJERO AUTOMÁTICO; 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 [26]	0x3D9	0x26F	0x0DF	0x3EC	incluso
CRC-10- GSM	redes móviles [23]	0x175	0x2BA	0x175	0x2BA	impar
CRC-11	FlexRay [37]	0x385	0x50E	0x21D	0x5C2	incluso
		${\displaystyle x^{11}+x^{9}+x^{8}+x^{7}+x^{2}+1}$
CRC-12	sistemas de telecomunicaciones [38] [39]	0x80F	0xF01	0xE03	0xC07 [11]	incluso
		${\displaystyle x^{12}+x^{11}+x^{3}+x^{2}+x+1}$
CRC-12- CDMA2000	redes móviles [26]	0xF13	0xC8F	0x91F	0xF89	incluso
CRC-12- GSM	redes móviles [23]	0xD31	0x8CB	0x197	0xE98	impar
CRC-13-BBC	Señal horaria, radioteleinterruptor [40] [41]	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 [27]	0x0805	0x2804	0x1009	0x2402	incluso
CRC-14- GSM	redes móviles [23]	0x202D	0x2D01	0x1A03	0x3016	incluso
CRC-15- PUEDE		0xC599 [42] [43]	0x4CD1	0x19A3	0x62CC	incluso
		${\displaystyle x^{15}+x^{14}+x^{10}+x^{8}+x^{7}+x^{4}+x^{3}+1}$
CRC-15- MPT1327	[44]	0x6815	0x540B	0x2817	0x740A	impar
CRC-16-Chakravarty	Óptimo para cargas útiles ≤ 64 bits [29]	0x2F15	0xA8F4	0x51E9	0x978A	impar
CRC-16- ARINC	Aplicaciones ACARS [45]	0xA02B	0xD405	0xA80B	0xD015	impar
CRC-16-CCITT	X.25 , V.41 , HDLC FCS , XMODEM , Bluetooth , PACTOR , SD , DigRF , muchos otros; conocido como CRC-CCITT	0x1021	0x8408	0x811	0x8810 [11]	incluso
		${\displaystyle x^{16}+x^{12}+x^{5}+1}$
CRC-16- CDMA2000	redes móviles [26]	0xC867	0xE613	0xCC27	0xE433	impar
CRC-16- DECT	teléfonos inalámbricos [46]	0x0589	0x91A0	0x2341	0x82C4	incluso
		${\displaystyle x^{16}+x^{10}+x^{8}+x^{7}+x^{3}+1}$
CRC-16- T10 - DIF	SCSI DIF	0x8BB7 [47]	0xEDD1	0xDBA3	0xC5DB	impar
		${\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 , M-Bus	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 conocido como CRC-16 y CRC-16-ANSI	0x8005	0xA001	0x4003	0xC002	incluso
		${\displaystyle x^{16}+x^{15}+x^{2}+1}$
CRC-16- OpenSafety -A	bus de campo de seguridad [33]	0x5935	0xAC9A	0x5935	0xAC9A [11]	impar
CRC-16- OpenSafety -B	bus de campo de seguridad [33]	0x755B	0xDAAE	0xB55D	0xBAAD [11]	impar
CRC-16- Profibus	redes de bus de campo [48]	0x1DCF	0xF3B8	0xE771	0x8EE7	impar
Fletcher-16	Utilizado en 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; ver suma de comprobación de Fletcher
CRC-17-CAN	CAN FD [49]	0x1685B	0x1B42D	0x1685B	0x1B42D	incluso
CRC-21-CAN	CAN FD [49]	0x102899	0x132281	0x064503	0x18144C	incluso
CRC-24	FlexRay [37]	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	Utilizado en OS-9 RTOS . Residuo = 0x800FE3. [50]	0x800063	0xC60001	0x8C0003	0xC00031	incluso	sí [51]	-	-	-	-	-	-	-	-	-	-	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 , [52] PNG , [53] ZMODEM , muchos otros	0x04C11DB7	0xEDB88320	0xDB710641	0x82608EDB [14]	impar	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)	Carga útil iSCSI , SCTP , G.hn , SSE4.2 , Btrfs , ext4 , Ceph	0x1EDC6F41	0x82F63B78	0x05EC76F1	0x8F6E37A0 [14]	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 en la longitud de la trama de Ethernet, bajo rendimiento con archivos largos	0x741B8CD7	0xEB31D82E	0xD663B05D	0xBA0DC66B [14]	incluso	No	2	-	4	-	dieciséis	-	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 en la longitud de la trama de Ethernet, bajo rendimiento con archivos largos	0x32583499	0x992C1A4C	0x32583499	0x992C1A4C [14]	incluso	No	-	-	3	-	dieciséis	-	26	-	134	-	32738	-	65506	-	∞
CRC-32Q	aviación; AIXM [54]	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; ver Adler-32
CRC-40- GSM	Canal de control GSM [55] [56] [57]	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, XZ Utils	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 el hash [58]	0x000000000000001B	0xD800000000000000	0xB000000000000001	0x800000000000000D	impar
		${\displaystyle x^{64}+x^{4}+x^{3}+x+1}$

Implementaciones

• Implementación de CRC32 en Gnuradio ;
• Código de clase C para el cálculo de la suma de comprobación CRC con muchos CRC diferentes para elegir

Catálogos CRC

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

Ver también

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

Referencias

1. "Un algoritmo para corregir errores de comprobaciones de redundancia cíclica" . drdobbs.com . Archivado desde el original el 20 de julio de 2017 . Consultado el 28 de junio de 2017 .
2. Peterson, WW; Brown, DT (enero de 1961). "Códigos cíclicos para la detección de errores". Actas de la IRE . 49 (1): 228–235. doi : 10.1109 / JRPROC.1961.287814 . S2CID 51666741 . 
3. Ritter, Terry (febrero de 1986). "El gran misterio de CRC" . Diario del Dr. Dobb . 11 (2): 26–34, 76–83 . Consultado el 21 de mayo de 2009 .
4. Stigge, Martin; Plötz, Henryk; Müller, Wolf; Redlich, Jens-Peter (mayo de 2006). "Revertir la CRC - teoría y práctica" (PDF) . Berlín: Universidad Humboldt de Berlín: 17. Archivado desde el original (PDF) el 19 de julio de 2011 . Consultado el 4 de febrero de 2011 . Los métodos presentados ofrecen una forma muy fácil y eficiente de modificar sus datos para que se computen en un CRC que desee o al menos conozca de antemano.
5. "diseño de algoritmos - ¿Por qué se dice que CRC es lineal?" . Intercambio de pila de criptografía . Consultado el 5 de mayo de 2019 .
6. Cam-Winget, Nancy; Housley, Russ; Wagner, David; Walker, Jesse (mayo de 2003). "Fallos de seguridad en los protocolos de enlace de datos 802.11" (PDF) . Comunicaciones de la ACM . 46 (5): 35–39. CiteSeerX 10.1.1.14.8775 . doi : 10.1145 / 769800.769823 . S2CID 3132937 .   
7. "[MS-ABS]: algoritmo CRC de 32 bits" . msdn.microsoft.com .
8. Williams, Ross N. (24 de septiembre de 1996). "Una guía indolora de algoritmos de detección de errores CRC V3.0" . Archivado desde el original el 2 de abril de 2018 . Consultado el 23 de mayo de 2019 .
9. Presione, WH; Teukolsky, SA; Vetterling, WT; Flannery, BP (2007). "Sección 22.4 Redundancia cíclica y otras sumas de comprobación" . Recetas numéricas: el arte de la informática científica (3ª ed.). Nueva York: Cambridge University Press. ISBN 978-0-521-88068-8.
10. Ewing, Gregory C. (marzo de 2010). "Ingeniería inversa de un algoritmo CRC" . Christchurch: Universidad de Canterbury . Consultado el 26 de julio de 2011 .
11. Koopman, Philip; Chakravarty, Tridib (junio de 2004). Selección de polinomio del código de redundancia cíclica (CRC) para redes integradas (PDF) . La Conferencia Internacional sobre Redes y Sistemas Confiables . págs. 145-154. CiteSeerX 10.1.1.648.9080 . doi : 10.1109 / DSN.2004.1311885 . ISBN   978-0-7695-2052-0. S2CID  793862 . Consultado el 14 de enero de 2011 .
12. Cook, Greg (15 de agosto de 2020). "Catálogo de algoritmos CRC parametrizados" . Consultado el 18 de septiembre de 2020 .
13. Castagnoli, G .; Bräuer, S .; Herrmann, M. (junio de 1993). "Optimización de códigos de verificación de redundancia cíclica con 24 y 32 bits de paridad". Transacciones IEEE sobre comunicaciones . 41 (6): 883–892. doi : 10.1109 / 26.231911 .
14. Koopman, Philip (julio de 2002). "Códigos de redundancia cíclica de 32 bits para aplicaciones de Internet". Proceedings International Conference on Dependable Systems and Networks (PDF) . La Conferencia Internacional sobre Redes y Sistemas Confiables . págs. 459–468. CiteSeerX 10.1.1.11.8323 . doi : 10.1109 / DSN.2002.1028931 . ISBN   978-0-7695-1597-7. S2CID  14775606 . Consultado el 14 de enero de 2011 .
15. Koopman, Philip (21 de enero de 2016). "Mejores polinomios de CRC" . Pittsburgh: Universidad Carnegie Mellon . Consultado el 26 de enero de 2016 .
16. Brayer, Kenneth (agosto de 1975). "Evaluación de polinomios de 32 grados en la detección de errores en los patrones de error de SATIN IV Autovon" . Servicio Nacional de Información Técnica : 74 . Consultado el 3 de febrero de 2011 . ^{[ enlace muerto permanente ]}
17. Hammond, Joseph L., Jr .; Brown, James E .; Liu, Shyan-Shiang (1975). "Desarrollo de un modelo de error de transmisión y un modelo de control de error" (PDF) . NASA Sti / Recon Technical Report N (publicado en mayo de 1975). 76 : 74. Código Bibliográfico : 1975STIN ... 7615344H . Consultado el 7 de julio de 2012 .
18. Brayer, Kenneth; Hammond, Joseph L., Jr. (diciembre de 1975). "Evaluación del comportamiento del polinomio de detección de errores en el canal AUTOVON". Registro de conferencia . Conferencia Nacional de Telecomunicaciones de IEEE, Nueva Orleans, Luisiana 1 . Nueva York: Instituto de Ingenieros Eléctricos y Electrónicos. págs. 8-21 a 8-25. Bibcode : 1975ntc ..... 1 .... 8B .
19. CRC con paridad par detectan cualquier número impar de errores de bits, a expensas de una menor distancia de martillo para cargas útiles largas. Tenga en cuenta que la paridad se calcula sobre todo el polinomio generador, incluido el 1 implícito al principio o al final. Por ejemplo, la representación completa de CRC-1 es 0x3, que tiene dos bits 1. Por tanto, su paridad es pareja.
20. "Zoológico CRC de 32 bits" . users.ece.cmu.edu .
21. Carga útil significa longitud sin incluir el campo CRC. Una distancia de Hamming de d significa que los errores de d - 1 bit pueden detectarse y los errores de ⌊ ( d  - 1) / 2⌋ bits pueden corregirse
22. siempre se logra para mensajes arbitrariamente largos
23. ETSI TS 100 909 (PDF) . V8.9.0. Sophia Antipolis, Francia: Instituto Europeo de Normas de Telecomunicaciones. Enero de 2005 . Consultado el 21 de octubre de 2016 .
24. "Zoológico CRC de 3 bits" . users.ece.cmu.edu .
25. Protocolo RFID UHF Clase 1 Generación 2 (PDF) . 1.2.0. EPCglobal . 23 de octubre de 2008. p. 35 . Consultado el 4 de julio de 2012 . (Tabla 6.12)
26. Estándar de capa física para sistemas de espectro ensanchado cdma2000 (PDF) . Revisión D versión 2.0. Proyecto de asociación de tercera generación 2. Octubre de 2005. págs. 2–89–2–92. Archivado desde el original (PDF) el 16 de noviembre de 2013 . Consultado el 14 de octubre de 2013 .
27. "11. Estrategia de corrección de errores". ETSI EN 300751 (PDF) . V1.2.1. Sophia Antipolis, Francia: Instituto Europeo de Normas de Telecomunicaciones. Enero de 2003. págs. 67–8 . Consultado el 26 de enero de 2016 .
28. "Zoológico CRC de 6 bits" . users.ece.cmu.edu .
29. Chakravarty, Tridib (diciembre de 2001). Rendimiento de códigos de redundancia cíclica para redes integradas (PDF) (Tesis). Philip Koopman, asesor. Pittsburgh: Universidad Carnegie Mellon. págs. 5, 18 . Consultado el 8 de julio de 2013 .
30. "5.1.4 Codificador CRC-8 (solo para flujos empaquetados)". EN 302 307 (PDF) . V1.3.1. Sophia Antipolis, Francia: Instituto Europeo de Normas de Telecomunicaciones. Marzo de 2013. p. 17 . Consultado el 29 de julio de 2016 .
31. "Zoológico CRC de 8 bits" . users.ece.cmu.edu .
32. "7.2.1.2 Cálculo de CRC polinomial 0x2F de 8 bits". Especificación de rutinas CRC (PDF) . 4.2.2. Múnich: AUTOSAR. 22 de julio de 2015. p. 24. Archivado desde el original (PDF) el 24 de julio de 2016 . Consultado el 24 de julio de 2016 .
33. "5.1.1.8 Campo de verificación de redundancia cíclica (CRC-8 / CRC-16)". Especificación del perfil de seguridad de openSAFETY: Borrador de trabajo de la propuesta 304 de EPSG . 1.4.0. Berlín: Grupo de estandarización Ethernet POWERLINK. 13 de marzo de 2013. p. 42. Archivado desde el original el 12 de agosto de 2017 . Consultado el 22 de julio de 2016 .
34. "Generación B.7.1.1 HEC". Especificación del sistema Bluetooth . 2 . Bluetooth SIG. 2 de diciembre de 2014. págs. 144–5 . Consultado el 20 de octubre de 2014 .
35. Harry Whitfield (24 de abril de 2001). "XFCN para cálculos de verificación de redundancia cíclica" . Archivado desde el original el 25 de mayo de 2005.
36. Richardson, Andrew (17 de marzo de 2005). Manual de WCDMA . Cambridge, Reino Unido: Cambridge University Press. pag. 223. ISBN 978-0-521-82815-4.
37. Especificación del protocolo FlexRay . 3.0.1. Consorcio Flexray. Octubre de 2010. p. 114. (4.2.8 CRC de encabezado (11 bits))
38. Pérez, A. (1983). "Cálculos CRC Byte-Wise". IEEE Micro . 3 (3): 40–50. doi : 10.1109 / MM.1983.291120 . S2CID 206471618 . 
39. Ramabadran, TV; Gaitonde, SS (1988). "Un tutorial sobre cálculos CRC". IEEE Micro . 8 (4): 62–75. doi : 10.1109 / 40.7773 . S2CID 10216862 . 
40. "Copia archivada" (PDF) . Archivado desde el original (PDF) el 24 de septiembre de 2015 . Consultado el 4 de noviembre de 2017 .
41. Ely, SR; Wright, DT (marzo de 1982). LF Radio-Data: especificación de las transmisiones experimentales de la BBC 1982 (PDF) . Departamento de Investigación, División de Ingeniería, The British Broadcasting Corporation. pag. 9 . Consultado el 11 de octubre de 2013 .
42. Comprobación de redundancia cíclica (CRC): Hoja de datos del componente PSoC Creator ™ . Semiconductor de ciprés. 20 de febrero de 2013. p. 4 . Consultado el 26 de enero de 2016 .
43. "Verificación de redundancia cíclica (CRC) en tramas CAN" . CAN en Automatización . Consultado el 26 de enero de 2016 .
44. "3.2.3 Codificación y comprobación de errores". Un estándar de señalización para sistemas de radio móviles terrestres privados troncalizados (MPT 1327) (PDF) (3ª ed.). Ofcom . Junio ​​de 1997. p. 3 . Consultado el 16 de julio de 2012 .
45. Rehmann, Albert; Mestre, José D. (febrero de 1995). "Informe de prueba preliminar del sistema de informes y comunicaciones de línea aérea VHF de enlace de datos aire-tierra (ACARS)" (PDF) . Centro técnico de la Autoridad Federal de Aviación: 5. Archivado desde el original (PDF) el 2 de agosto de 2012 . Consultado el 7 de julio de 2012 .
46. "6.2.5 Control de errores". ETSI EN 300175-3 (PDF) . V2.5.1. Sophia Antipolis, Francia: Instituto Europeo de Normas de Telecomunicaciones. Agosto de 2013. págs. 99, 101 . Consultado el 26 de enero de 2016 .
47. Thaler, Pat (28 de agosto de 2003). "Selección de polinomio CRC de 16 bits" (PDF) . INCITOS T10 . Consultado el 11 de agosto de 2009 .
48. "8.8.4 Comprobar octeto (FCS)". Piezas normativas de especificación PROFIBUS (PDF) . 1.0. 9 . Profibus International. Marzo de 1998. p. 906. Archivado desde el original (PDF) el 16 de noviembre de 2008 . Consultado el 9 de julio de 2016 .
49. CAN con especificación de velocidad de datos flexible (PDF) . 1.0. Robert Bosch GmbH. 17 de abril de 2012. p. 13. Archivado desde el original (PDF) el 22 de agosto de 2013. (3.2.1 MARCO DE DATOS)
50. "Manual del programador del sistema operativo OS-9" . www.roug.org .
51. Philip P. Koopman (20 de mayo de 2018). "Zoológico CRC de 24 bits" . users.ece.cmu.edu .
52. "cksum" . pubs.opengroup.org .
53. Boutell, Thomas; Randers-Pehrson, Glenn; et al. (14 de julio de 1998). "Especificación PNG (Gráficos de red portátiles), versión 1.2" . Libpng.org . Consultado el 3 de febrero de 2011 .
54. Imprimación AIXM (PDF) . 4.5. Organización europea para la seguridad de la navegación aérea . 20 de marzo de 2006 . Consultado el 3 de febrero de 2019 .
55. ETSI TS 100909 versión 8.9.0 (enero de 2005), sección 4.1.2 a
56. Gammel, Berndt M. (31 de octubre de 2005). Documentación de Matpack: Crypto - Codes . Matpack.de . Consultado el 21 de abril de 2013 . (Nota: MpCRC.html se incluye con el código fuente del software comprimido Matpack, en / html / LibDoc / Crypto)
57. Geremia, Patrick (abril de 1999). "Cálculo de verificación de redundancia cíclica: una implementación utilizando el TMS320C54x" (PDF) (SPRA530). Texas Instruments: 5 . Consultado el 4 de julio de 2012 .
58. Jones, David T. "Una comprobación de redundancia cíclica mejorada de 64 bits para secuencias de proteínas" (PDF) . University College de Londres . Consultado el 15 de diciembre de 2009 .

Lectura adicional

• Warren Jr., Henry S. (2013). Hacker's Delight (2 ed.). Addison Wesley - Pearson Education, Inc. ISBN 978-0-321-84268-8.

Enlaces externos

• Mitra, Jubin; Nayak, Tapan (enero de 2017). "Arquitectura de diseño VLSI (FPGA) reconfigurable de muy alto rendimiento y baja latencia de CRC 32". Integración, el VLSI Journal . 56 : 1-14. doi : 10.1016 / j.vlsi.2016.09.005 .
• Comprobaciones de redundancia cíclica , MathPages, descripción general de la detección de errores de diferentes polinomios
• Williams, Ross (1993). "Una guía indolora de algoritmos de detección de errores CRC" . Archivado desde el original el 3 de septiembre de 2011 . Consultado el 15 de agosto de 2011 .
• Negro, Richard (1994). "CRC32 rápido en software" . El Libro Azul . Grupo de Investigación de Sistemas, Laboratorio de Computación, Universidad de Cambridge. El algoritmo 4 se utilizó en Linux y Bzip2.
• Kounavis, M .; Berry, F. (2005). "Un enfoque sistemático para la construcción de generadores CRC basados ​​en software de alto rendimiento" (PDF) . Intel., Algoritmos de corte por 4 y corte por 8
• Kowalk, W. (agosto de 2006). "Análisis de verificación de redundancia cíclica CRC y corrección de errores" (PDF) . Universität Oldenburg. - Bitfilters
• Warren, Henry S., Jr. "Comprobación de redundancia cíclica" (PDF) . Delicia del hacker . Archivado desde el original (PDF) el 3 de mayo de 2015. - teoría, práctica, hardware y software con énfasis en CRC-32.
• Ingeniería inversa de un algoritmo CRC
• Cook, Greg. "Catálogo de algoritmos CRC parametrizados" . CRC RevEng .
• Koopman, Phil. "Blog: Checksum y CRC Central" .- incluye enlaces a archivos PDF que proporcionan distancias de Hamming CRC de 16 y 32 bits
• Koopman, Philip; Driscoll, Kevin; Hall, Brendan (marzo de 2015). "Código de redundancia cíclica y algoritmos de suma de comprobación para garantizar la integridad de los datos críticos" (PDF) . Administración Federal de Aviación. DOT / FAA / TC-14/49.

• 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 de Linux CRC32-Castagnoli