Verificación de redundancia cíclica

format_list_bulleted Contenido keyboard_arrow_down
ImprimirCitar
Código de detección de errores para detectar cambios de datos

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 − 2n).

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:

Ejemplos de representaciones de la CRC
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 bit0x1 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-CCITT0x1021 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-ANSI0x8005 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

Las ciencias de la información es un campo académico que se ocupa principalmente del análisis, la recopilación, la clasificación, la manipulación, el...

Host

Un host de red o dispositivo anfitrión es una computadora u otro dispositivo conectado a una red de computadoras. Un host puede funcionar como un servidor...

Lenguaje de programación de cuarta generación

Más resultados...
Tamaño del texto:
undoredo
format_boldformat_italicformat_underlinedstrikethrough_ssuperscriptsubscriptlink
save