Verificación de redundancia cíclica
Una comprobación de redundancia cíclica (CRC) es un código de detección de errores comúnmente utilizado en redes digitales y dispositivos de almacenamiento para detectar cambios accidentales en los datos digitales. Los bloques de datos que ingresan a estos sistemas obtienen un breve valor de verificación adjunto, basado en el resto de una división polinomial de sus contenidos. 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).
Los CRC se denominan así porque el valor check (verificación de datos) es una redundancia (amplía el mensaje sin agregar información) y el algoritmo se basa en códigos cíclicos. Los CRC son populares porque son fáciles 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 una función hash.
Introducción
Los CRC se basan en la teoría de los códigos de corrección de errores cíclicos. W. Wesley Peterson propuso por primera vez en 1961 el uso de códigos cíclicos sistemáticos, que codifican mensajes agregando un valor de verificación de longitud fija, con el fin de detectar errores en las redes de comunicación. Los códigos cíclicos no solo son fáciles de implementar, sino que tienen la ventaja de ser particularmente 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 óptico y magnético. Por lo general, un CRC de n bits 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 llamado polinomio generador. Este polinomio se convierte en el divisor en una división larga de polinomios, que toma el mensaje como dividendo y en la que se descarta el cociente y el resto se convierte en el resultado. La advertencia importante es que los coeficientes polinómicos 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 bit a bit (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, y coinciden cómodamente con la arquitectura de la computadora.
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 varios CRC, cada uno con un polinomio diferente. Dicho polinomio tiene el grado más alto n, lo que significa que tiene términos n + 1. 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 eliminan 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 se muestra 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.
Solicitud
Un dispositivo habilitado para CRC calcula una secuencia binaria corta de longitud fija, conocida como valor de verificación o CRC, para cada bloque de datos que se enviará o almacenará y lo agrega a los datos, formando una palabra clave.
Cuando se recibe o lee una palabra clave, 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 clave y compara el valor de verificación resultante con un residuo esperado constante.
Si los valores de CRC no coinciden, 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 de nuevo. 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).
Integridad de datos
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 la 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í mismos no protegen contra la modificación intencional de los datos. Cualquier aplicación que requiera protección contra este tipo de ataques debe utilizar mecanismos de autenticación criptográficos, 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.
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):
- CRC ()x⊕ ⊕ Sí.)=CRC ()x)⊕ ⊕ CRC ()Sí.)⊕ ⊕ c{displaystyle operatorname {CRC} (xoplus y)=operatorname {CRC} (x)oplus operatorname {CRC} (y)oplus c}
Donde c{displaystyle c} depende de la longitud x{displaystyle x} y Sí.{displaystyle y}. Esto también se puede decir de la siguiente manera: x{displaystyle x}, Sí.{displaystyle y} y z{displaystyle z} tienen la misma longitud
- CRC ()x⊕ ⊕ Sí.⊕ ⊕ z)=CRC ()x)⊕ ⊕ CRC ()Sí.)⊕ ⊕ CRC ()z);{displaystyle operatorname {CRC} (xoplus yoplus z)=operatorname {CRC} (x)oplus operatorname {CRC} (y)oplus operatorname {CRC} (z);}
como resultado, incluso si el CRC se cifra con un cifrado de flujo que usa XOR como su operación de combinación (o un 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 puede manipularse sin conocimiento de la clave de cifrado; este fue uno de los defectos de diseño más conocidos del protocolo de privacidad equivalente por cable (WEP).
Cálculo
Para calcular un CRC binario de n bits, alinee los bits que representan la entrada en una fila y coloque (n + Patrón de 1 bit 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 x3 + x + 1. El polinomio se escribe en binario como los coeficientes; un polinomio de tercer grado tiene 4 coeficientes (1x3 + 0x2 + 1x + 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
Esto se rellena primero 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 derecho acolchado por 3 bits 1011 ---- divisor (4 bits) = x3 + x + 1 - Sí. 01100011101100 000
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 arriba del divisor simplemente se copian directamente debajo para ese paso. Luego, el divisor se desplaza a la derecha para alinearse con el bit 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 derecho acolchado por 3 bits 1011 - Divisor 01100011101100 000 - resultado (nota los primeros cuatro bits son el XOR con el divisor debajo, el resto de los bits no se cambian) 1011 - Divisor... 00111011101100 000 1011 000 1011 00000001101100 000 --- note que el divisor se mueve para alinearse con el próximo 1 en el dividendo (ya que el cociente para ese paso era cero) 1011 (en otras palabras, no necesariamente mueve un poco por iteración) 00000000110100 000 1011 000 1011 00000001110 000 1011 00000000101 000 101 1 - Sí. 00000000000000000 100 --- resto (3 bits). El algoritmo de división se detiene aquí como 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 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 procesamiento posterior).
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.
11010011101100 100 1011 - Divisor 01100011101100 100 1011 - Divisor... 00111011101100 100 ... 00000001110 100 1011 00000000101 100 101 1 - Sí. 00000000000000000000000000000000000000000000000000000
El siguiente código de Python describe una función que devolverá el resto CRC inicial para una entrada y un polinomio seleccionados, 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 procesar:
def crc_remainder()input_bitstring, polinomial_bitstring, inicial_filler): """Calcula la CRC permanece de una cadena de bits usando un polinomio elegido. inicial_filler debe ser '1' o '0'. " polinomial_bitstring = polinomial_bitstring.Istrip()'0') len_input = Len()input_bitstring) inicial_padding = ()Len()polinomial_bitstring) - 1) * inicial_filler input_padded_array = lista()input_bitstring + inicial_padding) mientras '1 ' dentro input_padded_array[:len_input]: cur_shift = input_padded_array.índice()'1 ') para i dentro rango()Len()polinomial_bitstring) input_padded_array[cur_shift + i]
= str()int()polinomial_bitstring[i] ! input_padded_array[cur_shift + i]) retorno ' '.Únase()input_padded_array[len_input:def crc_check()input_bitstring, polinomial_bitstring, check_value): """Calcular el cheque de CRC de una cadena de bits usando un polinomio elegido."" polinomial_bitstring = polinomial_bitstring.Istrip()'0') len_input = Len()input_bitstring) inicial_padding = check_value input_padded_array = lista()input_bitstring + inicial_padding) mientras '1 ' dentro input_padded_array[:len_input]: cur_shift = input_padded_array.índice()'1 ') para i dentro rango()Len()polinomial_bitstring) input_padded_array[cur_shift + i]
= str()int()polinomial_bitstring[i] ! input_padded_array[cur_shift + i]) retorno ()'1 ' no dentro ' '.Únase()input_padded_array[len_input:)
, titulado crc_remainder()'11010011101100 ', '1011 ', '0')'100 ', titulado crc_check()'11010011101100 ', '1011 ', '100 ')Cierto.
Algoritmo CRC-32
Este es un algoritmo práctico para la variante CRC-32 de CRC. La CRCTable es una memorización de un cálculo que tendría que repetirse para cada byte del mensaje (Cálculo de verificaciones de redundancia cíclica § Cómputo de bits múltiples).
Función CRC32 Entrada:datos: Bytes // Array of bytes Producto:crc32: UInt32 // 32 bits sin signed CRC-32 valor
// Inicializar CRC-32 al valor inicialcrc32 ← 0xFFFF
para cada uno byte dentro datos donLookupIndex ← (crc32 xor byte) y 0x FF crc32 ← (crc32 shr 8) xor CRCTable[nLookupIndex] // CRCTable es una serie de 256 constantes de 32 bits
// Finalizar el valor CRC-32 invirtiendo todos los bitscrc32 ← crc32 xor 0xFFFF retorno crc32
En C, el algoritmo se ve así:
#include Identificaciones.h // uint32_t, uint8_tuint32_t CRC32()const uint8_t datos[], size_t data_length) {}uint32_t crc32 = 0xFFFFFFu;para ()size_t i = 0; i . data_length; i++) {}const uint32_t LookupIndex = ()crc32 ^ datos[i]) " 0xff;crc32 = ()crc32 > 8) ^ CRCTable[LookupIndex]; // CRCTable es una serie de 256 constantes de 32 bits}// Finalizar el valor CRC-32 invirtiendo todos los bitscrc32 ^= 0xFFFFFFu;retorno crc32;}
Matemáticas
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 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ño de 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 mientras se minimizan las probabilidades generales de colisión.
El atributo más importante del polinomio es su longitud (mayor grado (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 polinómicas más utilizadas son 9 bits (CRC-8), 17 bits (CRC-16), 33 bits (CRC-32) y 65 bits (CRC-64).
Un CRC se denomina CRC de n bits cuando su valor de comprobación es n bits. Para un n dado, son posibles varios CRC, cada uno con un polinomio diferente. Dicho polinomio 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 funciones de protección contra errores deseadas y el tipo de recursos para implementar el CRC, así como el rendimiento deseado. Un concepto erróneo común es que el "mejor" Los 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. 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 dará como resultado una cierta proporción de errores perdidos, debido a que el anillo del cociente tiene divisores cero.
La ventaja de elegir un polinomio primitivo como generador para un código CRC es que el código resultante tiene la longitud máxima total del bloque en el sentido de que todos los errores de 1 bit dentro de esa longitud del bloque tienen diferentes restos (también llamados síndromes) y por lo tanto, ya que el resto es una función lineal del bloque, el código puede detectar todos los errores de 2 bits dentro de esa longitud del bloque. Si r{displaystyle r} es el grado del generador primitivo polinomio, entonces la longitud total del bloque maximal es 2r− − 1{displaystyle 2^{r}-1}, y el código asociado es capaz de detectar cualquier error de un solo bit o de doble bit. Podemos mejorar esta situación. Si utilizamos el polinomio del generador g()x)=p()x)()1+x){displaystyle g(x)=p(x)(1+x)}, donde p{displaystyle p} es un polinomio primitivo de grado r− − 1{displaystyle r-1}, entonces la longitud total de bloque maximal es 2r− − 1− − 1{displaystyle 2^{r-1}-1}, y el código es capaz de detectar un número único, doble, triple y cualquier número impar de errores.
Un polinomio g()x){displaystyle g(x)} que admite otras factorizaciones puede ser elegido entonces para equilibrar el bloqueo total máximo con un poder de detección de errores deseado. Los códigos BCH son una clase poderosa de tales polinomios. Suman los dos ejemplos anteriores. Independientemente de las propiedades de reducibilidad de un generador polinomio de grador, si incluye el término "+1", el código será capaz de detectar patrones de error que se limitan a una ventana de r bits contiguos. Estos patrones se llaman "rupciones terroristas".
Especificación
El concepto de CRC como un código de detección de errores se complica cuando un implementador o un comité de estándares lo usa para diseñar un sistema práctico. Estas son algunas de las complicaciones:
- A veces una aplicación prefijos un patrón de bit fijo al bitstream para ser revisado. Esto es útil cuando los errores de relojería pueden insertar 0 bits delante de un mensaje, una alteración que de otra manera dejaría sin cambios el valor de verificación.
- Normalmente, pero no siempre, una implementación apéndices n 0-bits ()n ser el tamaño de la CRC) en el bitstream que se revisará antes de que se produzca la división polinomio. Este gasto se demuestra explícitamente en el artículo de la Convención sobre los Derechos del Niño. Esto tiene la conveniencia de que el resto del bitstream original con el valor de verificación anexado sea exactamente cero, por lo que el CRC se puede comprobar simplemente realizando la división polinomio en el bitstream recibido y comparando el resto con cero. Debido a las propiedades asociativas y comunicativas de la operación exclusiva, las implementaciones prácticas impulsadas por tablas pueden obtener un resultado numéricamente equivalente a cero-appendiendo sin incluir explícitamente ningún cero, utilizando un algoritmo equivalente y más rápido que combina el bitstream del mensaje con el flujo que se desplaza fuera del registro de CRC.
- A veces una aplicación exclusiva-ORs un patrón de bit fijo en el resto de la división polinomio.
- Orden: Algunos esquemas ven el pedazo de orden bajo de cada byte como "primero", que entonces durante la división polinomio significa "izquierda", que es contraria a nuestro entendimiento consuetudinario de "bajo orden". Esta convención tiene sentido cuando las transmisiones de puerto serie son revisadas por CRC en hardware, ya que algunas convenciones de transmisión en serie transmiten bytes menos significativos primero.
- Orden Byte: Con los CRC de múltiples bytes, puede haber confusión sobre si el byte transmitido primero (o almacenado en el byte de memoria más bajo abordado) es el byte menos significativo (LSB) o el byte más significativo (MSB). Por ejemplo, algunos esquemas de 16 bits de CRC intercambian los bytes del valor de verificación.
- Omisión del bit de alto orden del polinomio divisor: Puesto que la parte de alto orden es siempre 1, y desde n-bit CRC debe definirse por unn + 1)-bit divisor que desborda un n- registro de bits, algunos escritores asumen que es innecesario mencionar la parte de alto orden del divisor.
- Omisión del bit bajo pedido del polinomio divisor: Puesto que el bit de bajo orden es siempre 1, autores como Philip Koopman representan polinomios con su bit de alto orden intacto, pero sin el bit de bajo orden (el x0{displaystyle x^{0} o 1 término). Esta convención codifica el polinomio completo con su grado en un entero.
Estas complicaciones significan que hay tres formas comunes de expresar un polinomio como un entero: los dos primeros, que son imágenes espejo en binario, son las constantes encontradas en código; el tercero es el número encontrado en los papeles de Koopman. En cada caso, se omite un término. Así que el polinomio x4+x+1{displaystyle x^{4}+x+1} puede ser transcrito como:
- 0x3 = 0b0011, que representa x4+()0x3+0x2+1x1+1x0){displaystyle x^{4}+(0x^{3}+0x^{2}+1x^{1}+1x^{0}} (MSB-primer código)
- 0xC = 0b1100, representación ()1x0+1x1+0x2+0x3)+x4{displaystyle (1x^{0}+1x^{1}+0x^{2}+0x^{3})+x^{4} (LB-primer código)
- 0x9 = 0b1001, que representa ()1x4+0x3+0x2+1x1)+x0{displaystyle (1x^{4}+0x^{3}+0x^{2}+1x^{1})+x^{0} (Notación Koopman)
En la siguiente tabla se muestran como:
Nombre | Normal | Inversa | Reciprocalidad inversa |
---|---|---|---|
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 se pueden aplicar ingeniería inversa utilizando métodos sencillos.
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, sirve para 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 la longitud de los mensajes. La cantidad de CRC distintos en uso ha confundido a los desarrolladores, una situación que los autores han tratado de abordar. Hay tres polinomios informados para CRC-12, veintidós definiciones contradictorias de CRC-16 y siete de CRC-32.
Los polinomios comúnmente aplicados no son los más eficientes posibles. Desde 1993, Koopman, Castagnoli y otros han investigado el espacio de polinomios entre 3 y 64 bits de tamaño, 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 la mejor de ellas con el objetivo de mejorar la capacidad de detección de errores de los futuros estándares. 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 estándares, CRC-32-IEEE, fue el resultado de un esfuerzo conjunto del Laboratorio de Roma y la División de Sistemas Electrónicos de la Fuerza Aérea por parte de 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: Technical Report 2956 de Brayer para Mitre, publicado en enero y publicado para difusión pública a través de DTIC en agosto, y el informe de Hammond, Brown y Liu para el Laboratorio de Roma, publicado en mayo. 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. 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. 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).
El cálculo CRC-32C se implementa en el hardware como una operación ( CRC32
) del conjunto de instrucciones SSE4.2, introducido por primera vez en los procesadores Intel' Microarquitectura Nehalem. La arquitectura ARM AArch64 también proporciona aceleración de hardware para las operaciones CRC-32 y CRC-32C.
Representaciones polinómicas de comprobaciones de redundancia cíclica
La tabla siguiente lista sólo los polinomios de los diversos algoritmos en uso. Las variaciones de un protocolo particular pueden imponer pre-inversión, post-inversión y pedidos de bits revertidos como se describe anteriormente. Por ejemplo, el CRC32 utilizado en Gzip y Bzip2 utiliza el mismo polinomio, pero Gzip emplea el pedido de bits invertidos, mientras que Bzip2 no. Tenga en cuenta que incluso los polinomios de paridad en GF(2) con grado mayor a 1 nunca son primitivos. Incluso el polinomio de paridad marcado como primitivo en esta tabla representa un polinomio primitivo multiplicado por ()x+1){displaystyle left(x+1right)}. El pedazo más significativo de un polinomio es siempre 1, y no se muestra en las representaciones hexagonales.
Nombre | Usos | Representaciones polinómicas | Paridad | Primitivo | Montones máximos de carga por distancia Hamming | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Normal | Inversa | Reciprocal | Reciprocalidad inversa | ≥ 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | ||||
CRC-1 | más hardware; también conocido como Parity bit | 0x1 | 0x1 | 0x1 | 0x1 | incluso | ||||||||||||||||
x+1{displaystyle x+1} | ||||||||||||||||||||||
CRC-3-GSM | redes móviles | 0x3 | 0x6 | 0x5 | 0x5 | extraño | Sí. | – | – | – | – | – | – | – | – | – | – | – | – | – | 4 | JUEGO |
x3+x+1{displaystyle x^{3}+x+1} | ||||||||||||||||||||||
CRC-4-ITU | UIT-T G.704, pág. 12 | 0x3 | 0xC | 0x9 | 0x9 | extraño | ||||||||||||||||
x4+x+1{displaystyle x^{4}+x+1} | ||||||||||||||||||||||
CRC-5-EPC | Gen 2 RFID | 0x09 | 0x12 | 0x05 | 0x14 | extraño | ||||||||||||||||
x5+x3+1{displaystyle x^{5}+x^{3}+1} | ||||||||||||||||||||||
CRC-5-ITU | UIT-T G.704, pág. 9 | 0x15 | 0x15 | 0x0B | 0x1A | incluso | ||||||||||||||||
x5+x4+x2+1{displaystyle x^{5}+x^{4}+x^{2}+1} | ||||||||||||||||||||||
CRC-5-USB | Paquetes de token USB | 0x05 | 0x14 | 0x09 | 0x12 | extraño | ||||||||||||||||
x5+x2+1{displaystyle x^{5}+x^{2}+1} | ||||||||||||||||||||||
CRC-6-CDMA2000-A | redes móviles | 0x27 | 0x39 | 0x33 | 0x33 | extraño | ||||||||||||||||
CRC-6-CDMA2000-B | redes móviles | 0x07 | 0x38 | 0x31 | 0x23 | incluso | ||||||||||||||||
CRC-6-DARC | Canal de radio de datos | 0x19 | 0x26 | 0x0D | 0x2C | incluso | ||||||||||||||||
CRC-6-GSM | redes móviles | 0x2F | 0x3D | 0x3B | 0x37 | incluso | Sí. | – | – | – | – | – | – | – | – | – | – | 1 | 1 | 25 | 25 | JUEGO |
x6+x5+x3+x2+x+1{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 | extraño | ||||||||||||||||
x6+x+1{displaystyle x^{6}+x+1} | ||||||||||||||||||||||
CRC-7 | sistemas de telecomunicaciones, UIT-T G.707, UIT-T G.832, MMC, SD | 0x09 | 0x48 | 0x11 | 0x44 | extraño | ||||||||||||||||
x7+x3+1{displaystyle x^{7}+x^{3}+1} | ||||||||||||||||||||||
CRC-7-MVB | Train Communication Network, IEC 60870-5 | 0x65 | 0x53 | 0x27 | 0x72 | extraño | ||||||||||||||||
CRC-8 | DVB-S2 | 0xD5 | 0xAB | 0x57 | 0xEA | incluso | no | – | – | – | – | – | – | – | – | – | – | 2 | 2 | 85 | 85 | JUEGO |
x8+x7+x6+x4+x2+1{displaystyle x^{8}+x^{7}+x^{6}+x^{4}+x^{2}+1} | ||||||||||||||||||||||
CRC-8-AUTOSAR | integración automotriz, OpenSafety | 0x2F | 0xF4 | 0xE9 | 0x97 | incluso | Sí. | – | – | – | – | – | – | – | – | – | – | 3 | 3 | 119 | 119 | JUEGO |
x8+x5+x3+x2+x+1{displaystyle x^{8}+x^{5}+x^{3}+x^{2}+x+1} | ||||||||||||||||||||||
CRC-8-Bluetooth | conectividad inalámbrica | 0xA7 | 0xE5 | 0xCB | 0xD3 | incluso | ||||||||||||||||
x8+x7+x5+x2+x+1{displaystyle x^{8}+x^{7}+x^{5}+x^{2}+x+1} | ||||||||||||||||||||||
CRC-8-CCITT | ITU-T I.432.1 (02/99); ATM HEC, ISDN HEC y delineación celular, SMBus PEC | 0x07 | 0xE0 | 0xC1 | 0x83 | incluso | ||||||||||||||||
x8+x2+x+1{displaystyle x^{8}+x^{2}+x+1} | ||||||||||||||||||||||
CRC-8-Dallas/Maxim | Autobús de 1-Wire | 0x31 | 0x8C | 0x19 | 0x98 | incluso | ||||||||||||||||
x8+x5+x4+1{displaystyle x^{8}+x^{5}+x^{4}+1} | ||||||||||||||||||||||
CRC-8-DARC | Canal de radio de datos | 0x39 | 0x9C | 0x39 | 0x9C | extraño | ||||||||||||||||
x8+x5+x4+x3+1{displaystyle x^{8}+x^{5}+x^{4}+x^{3}+1} | ||||||||||||||||||||||
CRC-8-GSM-B | redes móviles | 0x49 | 0x92 | 0x25 | 0xA4 | incluso | ||||||||||||||||
x8+x6+x3+1{displaystyle x^{8}+x^{6}+x^{3}+1} | ||||||||||||||||||||||
CRC-8-SAE J1850 | AES3; OBD | 0x1D | 0xB8 | 0x71 | 0x8E | extraño | ||||||||||||||||
x8+x4+x3+x2+1{displaystyle x^{8}+x^{4}+x^{3}+x^{2}+1} | ||||||||||||||||||||||
CRC-8-WCDMA | redes móviles | 0x9B | 0xD9 | 0xB3 | 0xCD | incluso | ||||||||||||||||
x8+x7+x4+x3+x+1{displaystyle x^{8}+x^{7}+x^{4}+x^{3}+x+1} | ||||||||||||||||||||||
CRC-10 | ATM; ITU-T I.610 | 0x233 | 0x331 | 0x263 | 0x319 | incluso | ||||||||||||||||
x10+x9+x5+x4+x+1{displaystyle x^{10}+x^{9}+x^{5}+x^{4}+x+1} | ||||||||||||||||||||||
CRC-10-CDMA2000 | redes móviles | 0x3D9 | 0x26F | 0x0DF | 0x3EC | incluso | ||||||||||||||||
CRC-10-GSM | redes móviles | 0x175 | 0x2BA | 0x175 | 0x2BA | extraño | ||||||||||||||||
CRC-11 | FlexRay | 0x385 | 0x50E | 0x21D | 0x5C2 | incluso | ||||||||||||||||
x11+x9+x8+x7+x2+1{displaystyle x^{11}+x^{9}+x^{8}+x^{7}+x^{2}+1} | ||||||||||||||||||||||
CRC-12 | sistemas de telecomunicaciones | 0x80F | 0xF01 | 0xE03 | 0xC07 | incluso | ||||||||||||||||
x12+x11+x3+x2+x+1{displaystyle x^{12}+x^{11}+x^{3}+x^{2}+x+1} | ||||||||||||||||||||||
CRC-12-CDMA2000 | redes móviles | 0xF13 | 0xC8F | 0x91F | 0xF89 | incluso | ||||||||||||||||
CRC-12-GSM | redes móviles | 0xD31 | 0x8CB | 0x197 | 0xE98 | extraño | ||||||||||||||||
CRC-13-BBC | Hora de la señal, Radio Teleswitch | 0x1CF5 | 0x15E7 | 0x0BCF | 0x1E7A | incluso | ||||||||||||||||
x13+x12+x11+x10+x7+x6+x5+x4+x2+1{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 | 0x0805 | 0x2804 | 0x1009 | 0x2402 | incluso | ||||||||||||||||
CRC-14-GSM | redes móviles | 0x202D | 0x2D01 | 0x1A03 | 0x3016 | incluso | ||||||||||||||||
CRC-15-CAN | 0xC599 | 0x4CD1 | 0x19A3 | 0x62CC | incluso | |||||||||||||||||
x15+x14+x10+x8+x7+x4+x3+1{displaystyle x^{15}+x^{14}+x^{10}+x^{8}+x^{7}+x^{4}+x^{3}+1} | ||||||||||||||||||||||
CRC-15-MPT1327 | 0x6815 | 0x540B | 0x2817 | 0x740A | extraño | |||||||||||||||||
CRC-16-Chakravarty | Optimal for payloads ≤64 bits | 0x2F15 | 0xA8F4 | 0x51E9 | 0x978A | extraño | ||||||||||||||||
CRC-16-ARINC | Aplicaciones ACARS | 0xA02B | 0xD405 | 0xA80B | 0xD015 | extraño | ||||||||||||||||
CRC-16-CCITT | X.25, V.41, HDLC FCS, XMODEM, Bluetooth, PACTOR, SD, DigRF, muchos otros; conocido como CRC-CCITT | 0x1021 | 0x8408 | 0x811 | 0x8810 | incluso | ||||||||||||||||
x16+x12+x5+1{displaystyle x^{16}+x^{12}+x^{5}+1} | ||||||||||||||||||||||
CRC-16-CDMA2000 | redes móviles | 0xC867 | 0xE613 | 0xCC27 | 0xE433 | extraño | ||||||||||||||||
CRC-16-DECT | Teléfonos inalámbricos | 0x0589 | 0x91A0 | 0x2341 | 0x82C4 | incluso | ||||||||||||||||
x16+x10+x8+x7+x3+1{displaystyle x^{16}+x^{10}+x^{8}+x^{7}+x^{3}+1} | ||||||||||||||||||||||
CRC-16-T10-DIF | SCSI DIF | 0xBB87 | 0xEDD1 | 0xDBA3 | 0xC5DB | extraño | ||||||||||||||||
x16+x15+x11+x9+x8+x7+x5+x4+x2+x+1{displaystyle x^{16}+x^{15}+x^{11}+x^{9}+x^{7}+x^{7}+x^{5}+x^{4}+x^{2}+x+1} | ||||||||||||||||||||||
CRC-16-DNP | DNP, IEC 870, M-Bus | 0x3D65 | 0xA6BC | 0x4D79 | 0x9EB2 | incluso | ||||||||||||||||
x16+x13+x12+x11+x10+x8+x6+x5+x2+1{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 | ||||||||||||||||
x16+x15+x2+1{displaystyle x^{16}+x^{15}+x^{2}+1} | ||||||||||||||||||||||
CRC-16-OpenSafety-A | campo de seguridad | 0x5935 | 0xAC9A | 0x5935 | 0xAC9A | extraño | ||||||||||||||||
CRC-16-OpenSafety-B | campo de seguridad | 0x755B | 0xDAAE | 0xB55D | 0xBAAD | extraño | ||||||||||||||||
CRC-16-Profibus | redes de empleo | 0x1DCF | 0xF3B8 | 0xE771 | 0x8EE7 | extraño | ||||||||||||||||
Fletcher-16 | Se utiliza en los cheques Adler-32 A & B | A menudo confundido para ser un CRC, pero en realidad un chequesum; vea la suma de comprobación de Fletcher | ||||||||||||||||||||
CRC-17-CAN | CAN FD | 0x1685B | 0x1B42D | 0x1685B | 0x1B42D | incluso | ||||||||||||||||
CRC-21-CAN | CAN FD | 0x102899 | 0x132281 | 0x064503 | 0x18144C | incluso | ||||||||||||||||
CRC-24 | FlexRay | 0x5D6DCB | 0xD3B6BA | 0xA76D75 | 0xAEB6E5 | incluso | ||||||||||||||||
x24+x22+x20+x19+x18+x16+x14+x13+x11+x10+x8+x7+x6+x3+x+1{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} | ||||||||||||||||||||||
CRC-24-Radix-64 | OpenPGP, RTCM104v3 | 0x864CFB | 0xDF3261 | 0xBE64C3 | 0xC3267D | incluso | ||||||||||||||||
x24+x23+x18+x17+x14+x11+x10+x7+x6+x5+x4+x3+x+1{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 | Usado en OS-9 RTOS. Residuo = 0x800FE3. | 0x800063 | 0xC60001 | 0x8C0003 | 0xC00031 | incluso | Sí. | – | – | – | – | – | – | – | – | – | – | 4 | 4 | 8388583 | 8388583 | JUEGO |
x24+x23+x6+x5+x+1{displaystyle x^{24}+x^{23}+x^{6}+x^{5}+x+1} | ||||||||||||||||||||||
CRC-30 | CDMA | 0x2030B9C7 | 0x38E74301 | 0x31CE8603 | 0x30185CE3 | incluso | ||||||||||||||||
x30+x29+x21+x20+x15+x13+x12+x11+x8+x7+x6+x2+x+1{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, PNG, ZMODEM, muchos otros | 0x04C11DB7 | 0xEDB88320 | 0xDB710641 | 0x82608EDB | extraño | Sí. | – | 10 | – | – | 12 | 21 | 34 | 57 | 91 | 171 | 268 | 2974 | 91607 | 4294967263 | JUEGO |
x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1{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, G.hn payload, SSE4.2, Btrfs, ext4, Ceph | 0x1EDC6F41 | 0x82F63B78 | 0x05EC76F1 | 0x8F6E37A0 | incluso | Sí. | 6 | – | 8 | – | 20 | – | 47 | – | 177 | – | 5243 | – | 2147483615 | – | JUEGO |
x32+x28+x27+x26+x25+x23+x22+x20+x19+x18+x14+x13+x11+x10+x9+x8+x6+1{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}+0}+x^{8}+0}+0}+0}+0}+0}+0}+0}+0}+0}+0}+x}}+x}}}}}}}+x}+x}}}}}}}}+x}+x}}}}}}}}+x}}}}}}+x}}+x}}}}}+x}}}}}}}}}}+x}+x}}+x}+0}}+x}}}}}}}}}}}}}}}}}}}}+x}+x}}}}}+x}}}}}}+x}} | ||||||||||||||||||||||
CRC-32K (Koopman {1,3,28}) | Excelente en la longitud del marco Ethernet, mal rendimiento con archivos largos | 0x741B8CD7 | 0xEB31D82E | 0xD663B05D | 0xBA0DC66B | incluso | no | 2 | – | 4 | – | 16 | – | 18 | – | 152 | – | 16360 | – | 114663 | – | JUEGO |
x32+x30+x29+x28+x26+x20+x19+x17+x16+x15+x11+x10+x7+x6+x4+x2+x+1{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}+0}+0}+0}+0} | ||||||||||||||||||||||
CRC-32K2 (Koopman {1,1,30}) | Excelente en la longitud del marco Ethernet, mal rendimiento con archivos largos | 0x32583499 | 0x992C1A4C | 0x32583499 | 0x992C1A4C | incluso | no | – | – | 3 | – | 16 | – | 26 | – | 134 | – | 32738 | – | 65506 | – | JUEGO |
CRC-32Q | aviación; AIXM | 0x8141AB | 0xD5828281 | 0xAB050503 | 0xC0A0A0D5 | incluso | ||||||||||||||||
x32+x31+x24+x22+x16+x14+x8+x7+x5+x3+x+1{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 confundido para ser un CRC, pero en realidad un chequesum; ver Adler-32 | |||||||||||||||||||||
CRC-40-GSM | Canal de control GSM | 0x0004820009 | 0x9000412000 | 0x2000824001 | 0x8002410004 | incluso | ||||||||||||||||
x40+x26+x23+x17+x3+1=()x23+1)()x17+x3+1){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. 51, XZ Utils | 0x42F0E1EBA9EA3693 | 0xC96C5795D7870F42 | 0x92D8AF2BAF0E1E85 | 0xA17870F5D4F51B49 | incluso | ||||||||||||||||
x64+x62+x57+x55+x54+x53+x52+x47+x46+x45+x40+x39+x38+x37+x35+x33+{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}+}+}+}+}}+x}}}+x}}+x}}}}+x^{38}+0}+0}}+0}+0}}+x}}+x}+0}+0}+0}+x}}}}}}}+x}}+x}}}}+x}+x}}+x}}}}+ x32+x31+x29+x27+x24+x23+x22+x21+x19+x17+x13+x12+x10+x9+x7+x4+x+1{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}+0}+x}+1} | ||||||||||||||||||||||
CRC-64-ISO | ISO 3309 (HDLC), Swiss-Prot/TrEMBL; considerado débil para la piratería | 0x000000000001B | 0xD800000000000000000 | 0xB000000000001 | 0x800000000000000D | extraño | ||||||||||||||||
x64+x4+x3+x+1{displaystyle x^{64}+x^{4}+x^{3}+x+1} |
Implementaciones
- Implementación de CRC32 en Radio GNU hasta 3.6.1 (ca. 2012)
- 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 parametrizados de CRC
- CRC Polynomial Zoo
Contenido relacionado
Ciencias de la Información
Host
Lenguaje de programación de cuarta generación