Las líneas usan la forma «ALGORITMO valor» seguida de una línea de parámetros con sangría, así que un resultado copiado y pegado siempre indica qué conjunto de parámetros lo produjo.
CRC: comprobación de redundancia cíclica, explicada desde cero
En una frase: un CRC trata sus datos como un número binario gigantesco, lo divide entre un número «generador» fijo usando XOR en lugar de resta, e informa del resto: una huella compacta que cambia de forma drástica cuando se invierte un solo bit de la entrada, por eso todo, desde los archivos PNG hasta los cables Modbus, lo lleva.
Qué es realmente un CRC
La imagen de la división. Alinee sus bytes como un único número binario largo. Elija un divisor, el polinomio, p. ej. 0x04C11DB7 para CRC-32. Realice la división binaria larga donde la «resta» es la operación XOR: siempre que el bit inicial del resto en curso sea 1, aplique XOR con el divisor, desplace a la izquierda y repita. Cuando todo el mensaje ha pasado, lo que quede en el registro es el CRC. Sin claves, sin tablas en la definición: solo una división con resto.
Los cinco parámetros. Dos sistemas pueden decir ambos «CRC-32» y aun así no coincidir, porque el nombre por sí solo no fija nada. La receta completa necesita cinco valores: poly (el divisor), init (con qué empieza el registro: todos ceros hace que desaparezcan los bytes cero iniciales; todos unos no), refin/refout (si cada byte de entrada, y el registro final, se invierte bit a bit, herencia del hardware serie que enviaba los bits del menos significativo al más significativo), y xorout (una máscara XOR final para que una serie de ceros al final también cambie el resultado). Esta página imprime los cinco junto a cada resultado precisamente por eso.
Por qué detecta errores. Un divisor bien elegido hace que el resto de un mensaje y el resto del mismo mensaje con unos pocos bits invertidos difieran con una probabilidad abrumadora: un buen CRC-32 detecta todos los errores de 1 y 2 bits, todos los números impares de errores de bit y cada ráfaga de hasta 32 bits consecutivos corruptos, garantizado, no probabilísticamente. Esa garantía se refiere a la corrupción accidental, y es lo que hace de los CRC la herramienta adecuada para cables ruidosos y discos defectuosos.
Lo que un CRC no es
No es un hash criptográfico. No hay secreto ni unidireccionalidad: cualquiera que conozca los parámetros puede falsificar un mensaje con el CRC que quiera, en milisegundos, añadiendo cuatro bytes de corrección. Un CRC detecta accidentes, nunca adversarios. Para descargas que verifica contra desconocidos, las firmas importan: consulte el Generador de hash (MD5/SHA/BLAKE2) en su lugar. Esa página también explica por qué MD5 y SHA-1 están retirados en entornos hostiles mientras SHA-256 sigue vigente.
No es un código de corrección de errores. Un CRC le dice que algo cambió, no qué cambió. Reparar errores al vuelo es tarea de códigos como Reed–Solomon o Hamming, que almacenan deliberadamente una estructura redundante que un decodificador puede invertir.
No es compresión ni cifrado. El resto ocupa unos pocos bytes independientemente del tamaño de la entrada, y a partir de él no se puede recuperar la entrada; pero, a diferencia de un hash criptográfico, eso se debe simplemente a que se descartó información, no a que invertirlo sea difícil.
Las familias de esta página
Los cuatrillizos CRC-32. Cuatro de las entradas de esta página comparten el polinomio 0x04C11DB7 y aun así producen valores distintos: ISO-HDLC (reflejado, init/xorout todos unos) es «el» CRC-32 de zlib, gzip, PNG y ZIP; BZIP2 es la misma matemática sin reflejar; MPEG-2 es BZIP2 sin XOR final; POSIX parte de cero y es la base del comando cksum (que además añade la longitud del archivo a la división, así que cksum de un archivo y CRC-32/POSIX de los mismos bytes difieren). CRC-32C (Castagnoli, polinomio 0x1EDC6F41) es el quinto hermano: otro polinomio elegido para un mejor rendimiento en la detección de errores, y el que las CPU x86 y ARM modernas pueden calcular a velocidad de memoria con una sola instrucción.
El cuarteto CRC-64. XZ usa el polinomio ECMA-182 en forma reflejada con init y xorout todos unos; ECMA-182 en sí es el original sin reflejar y con init cero del estándar de cinta DLT-1; GO-ISO es crc64.ISO de Go, un polinomio pequeño 0x1B, todavía reflejado; REDIS usa un polinomio elegido por su buena difusión en la asignación de slots de hash. Sesenta y cuatro bits es el tamaño en el que los CRC empiezan a usarse como funciones hash (para agrupar en cubos) en lugar de como simples sumas de comprobación.
Adler-32 es el outsider: no es una división en absoluto. Suma los bytes (A, empezando en 1) y suma esas sumas (B), ambas módulo 65521, y concatena las dos sumas de 16 bits. Es más rápido que CRC-32 en software, y zlib lo usa para flujos deflate; pero para entradas cortas (menos de unos cientos de bytes) la suma lleva muy poca información, y por eso zlib vuelve a CRC-32 en bloques pequeños.
CRC-8 y CRC-16 sobreviven donde los bytes son caros: CRC-8/CCITT (polinomio 0x07) protege bytes de cabecera individuales en SMBus y en protocolos de radio celular; CRC-16/CCITT-FALSE protege bloques de tarjetas inteligentes; CRC-16/MODBUS es la suma de comprobación de cada trama Modbus RTU en las fábricas de todo el mundo.
Dónde se usa cada uno
| Conjunto de parámetros | Dónde aparece |
|---|
| CRC-32/ISO-HDLC | zlib, gzip, PNG, ZIP, Ethernet (FCS), muchos formatos de archivo |
| CRC-32C | iSCSI, ext4, btrfs, ZFS, instrucción CRC32C por hardware de SSE4.2/ARMv8 |
| CRC-32/BZIP2 | flujo de archivo .bz2 |
| CRC-32/MPEG-2 | flujos de transporte MPEG-2 |
| CRC-32/POSIX & cksum | salida del comando POSIX cksum (cksum archivo.txt) |
| CRC-16/MODBUS | tramas Modbus RTU (PLC industriales, contadores, inversores) |
| CRC-16/CCITT-FALSE | tarjetas inteligentes, enlaces afines a X.25, algunos protocolos GPS |
| CRC-8/CCITT | SMBus (byte PEC), cabeceras de radio celular |
| CRC-64/XZ | comprobaciones de integridad del contenedor .xz |
| CRC-64/ECMA-182 | ECMA-182 / estándar de cinta DLT-1 |
| CRC-64/GO-ISO | biblioteca estándar de Go crc64.ISO |
| CRC-64/REDIS | asignación de slots de hash del clúster de Redis |
| Adler-32 | flujos zlib (deflate), otros contextos de suma de comprobación rápida |
La tabla de anclas: check(“123456789”)
La convención del catálogo de CRC es publicar el resultado de la cadena ASCII 123456789 (9 bytes). Cada valor de abajo puede reproducirse en esta página: escriba 123456789 en el cuadro de texto, marque el algoritmo y pulse Calcular.
| Conjunto de parámetros | Ancho | Valor de comprobación (hex) |
|---|
| CRC-8/CCITT | 8 | 0xf4 |
| CRC-16/CCITT-FALSE | 16 | 0x29b1 |
| CRC-16/MODBUS | 16 | 0x4b37 |
| CRC-32/ISO-HDLC | 32 | 0xcbf43926 |
| CRC-32C | 32 | 0xe3069283 |
| CRC-32/BZIP2 | 32 | 0xfc891918 |
| CRC-32/MPEG-2 | 32 | 0x0376e6e7 |
| CRC-32/POSIX | 32 | 0x765e7680 |
| cksum (POSIX command) | 32 | 0x377a6011 |
| CRC-64/XZ | 64 | 0x995dc9bbdf1939fa |
| CRC-64/ECMA-182 | 64 | 0x6c40df5f0b497347 |
| CRC-64/GO-ISO | 64 | 0xb90956c775a41001 |
| CRC-64/REDIS | 64 | 0xe9c6d914c4b8d9ca |
| Adler-32 | 32 | 0x091e01de |
Fuentes: cada valor se contrastó con una implementación bit a bit de referencia independiente y, cuando existe, con la biblioteca del sistema que incluye el algoritmo (zlib para CRC-32 y Adler-32; el catálogo de CRC de Greg Cook para el resto).
Errores habituales
- «CRC-32» sin parámetros. Entre ISO-HDLC, BZIP2, MPEG-2, POSIX y CRC-32C, circulan cinco valores distintos con el mismo nombre. Registre siempre polinomio/init/refin/refout/xorout junto con el resultado: esta página los imprime por usted.
- Comparar el CRC-32 de un archivo con la salida de
cksum. Algoritmos distintos: cksum añade la longitud y usa otro init. Los números no coincidirán, y ambos son «correctos».
- Confiar en el CRC frente a la manipulación. Falsificar un CRC coincidente es un ejercicio de manual (parchear los últimos 4 bytes). Use un MAC con clave (HMAC) o una firma cuando la otra parte pueda ser hostil.
- Esperar efecto avalancha. Un CRC es lineal: mensajes relacionados dan CRC relacionados. Bien para el ruido, incorrecto para hash: si necesita agrupar en cubos, CRC-64 o un hash real es más seguro que CRC-32.
- Texto hexadecimal frente a bytes. La cadena
"123456789" (9 bytes ASCII, 31 32 33 34 35 36 37 38 39) y el número 0x123456789 son entradas distintas con CRC distintos. Use la pestaña de bytes hexadecimales cuando sus datos de origen sean realmente binarios.
Preguntas frecuentes
¿Por qué mi CRC-32 no coincide con el del archivo ZIP? El CRC-32 de ZIP es ISO-HDLC sobre los datos sin comprimir. Asegúrese de haber calculado sobre los mismos bytes (no sobre el flujo comprimido), en el mismo modo (texto o hexadecimal) y con el mismo conjunto de parámetros: la línea de parámetros impresa bajo cada resultado sirve para hacer esa comprobación al instante.
¿Cuál es mejor, CRC-32C o CRC-32? Para la detección de errores accidentales, ambos detectan todas las ráfagas de hasta 32 bits; CRC-32C funciona mejor con algunos patrones de error y es el que tiene instrucciones en la CPU, prácticamente gratis a velocidades de gigabit. La razón por la que sobrevive CRC-32/ISO-HDLC es la compatibilidad: treinta años de archivos lo hablan.
¿Es CRC-64 más fuerte que CRC-32? Detecta ráfagas más largas (hasta 64 bits) y colisiona mucho menos cuando se usa para agrupar en cubos, pero es igual de falsificable: la anchura compra garantías de detección, no seguridad.
¿Se puede invertir un CRC para revelar la entrada? No: infinitas entradas comparten un mismo CRC. Pero, a diferencia de un hash criptográfico, un atacante puede construir una entrada con el CRC que elija, que es el sentido en el que no es unidireccional en absoluto.
