Calculadora CRC-32 - Checksum de texto, hex y archivos

Se usa en todas partes donde una comprobación barata y casi segura contra corrupción accidental vale más que una garantía de seguridad. Cada archivo ZIP guarda una por entrada en su directorio central, y unzip la verifica al extraer, de modo que un archivo truncado o con bits cambiados se reporta como tal en lugar de producir basura en silencio. gzip y zlib añaden un CRC-32 al final de su flujo comprimido, y por eso un .gz corrupto produce un error de checksum en vez de un inexplicable fallo de descompresión. PNG guarda un CRC-32 en cada fragmento, tanto para validar cada bloque por separado como para permitir que el decodificador se detenga en el primero defectuoso. Los flujos de transporte MPEG-2 llevan uno por paquete, y la secuencia de verificación de trama de Ethernet es un CRC-32 calculado normalmente por el hardware de la tarjeta en cada trama que atraviesa un conmutador. En todos esos casos el modelo de amenaza es el mismo: ruido, degradación, escrituras parciales y versiones que no coinciden, no un atacante decidido.

No, y usarlo para contraseñas o para verificar la integridad de una descarga que viene de una fuente no confiable sería un error grave. Un CRC es una función lineal sobre el campo GF(2), lo que significa que hacer una O-exclusiva con la misma diferencia en dos mensajes produce la misma diferencia en sus sumas. Por eso quien conoce un mensaje y su suma puede construir otro mensaje, distinto en apenas cuatro bytes, con la suma que le parezca. Es una falsificación que no requiere ingenio ni búsqueda. Además, con solo 32 bits de ancho un atacante puede precalcular una colisión en segundos con una GPU. No tiene clave, ni sal, ni factor de coste, ni comportamiento de avalancha, así que no aporta ninguna de las propiedades de unidireccionalidad, imprevisibilidad o resistencia a la fuerza bruta de las que dependen el almacenamiento de contraseñas y la firma de código. Usa un hash criptográfico como SHA-256 para integridad frente a un adversario, y una función específica como Argon2id o bcrypt para cualquier cosa que tenga forma de credencial.

Porque los dos nombres describen el mismo algoritmo envuelto en encuadres ligeramente distintos. La fila CRC-32b de esta calculadora ejecuta el algoritmo idéntico sobre tus bytes con un byte 0x00 final añadido, y ese byte extra cambia el estado del registro, así que todos los valores se desplazan. El propósito de una variante así es distinguir la carga de su propio terminador, para que un flujo que termina legítimamente en un byte nulo no se confunda con otro que termina ahí por accidente. Conviene saber que el término se usa de forma inconsistente: la variante BZIP2, que normalmente se escribe CRC-32/BZIP2 y que se identifica por el valor de comprobación 0xCBF43926 para la cadena 123456789, añade cuatro bytes nulos en lugar de uno y es una función distinta. Si vas a interoperar con una herramienta o un formato concreto, comprueba qué añade realmente esa implementación en vez de confiar en el nombre.

Es la forma reflejada del polinomio generador del CRC-32, 0x04C11DB7, y aparece en prácticamente cualquier implementación de CRC-32 que vayas a encontrar. El polinomio generador define qué patrones de bits se consideran error. Su forma normal, con los bits en orden directo, es la representación de los libros de texto, pero el orden reflejado permite ejecutar todo el cálculo de derecha a izquierda a través de los bytes, lo que necesita una consulta de tabla y un desplazamiento por byte en lugar de ocho desplazamientos condicionales. En la implementación reflejada, el valor 0x04C11DB7 se invierte a 0xEDB88320, y cada una de las 256 entradas de la tabla se genera empezando por el valor de un byte y aplicando ocho veces ese bucle de inversión: si el bit menos significativo está a uno, se hace la O-exclusiva con 0xEDB88320 y se desplaza a la derecha; si no, solo se desplaza. Construir la tabla desde esa definición, como hace esta herramienta, es más seguro que pegar un array de 256 entradas, porque elimina la posibilidad de que la tabla entregada se desvíe de la definición que dice implementar.

Porque el espacio de salida solo tiene 32 bits, así que hay unos 4290 millones de sumas posibles para repartirse entre todos los mensajes posibles, y es inevitable que algunas compartan una. Aplicando el principio del palomar, el número de mensajes necesario para que una colisión sea probable es aproximadamente la raíz cuadrada de 2^32, es decir, unos 65536, de modo que los datos aleatorios encuentran un CRC duplicado por ahí. Los archivos reales son peores que los aleatorios, porque los documentos estructurados suelen diferir en unos pocos sitios predecibles. Esto no es un defecto del diseño, es el diseño funcionando como se pretendía. Un CRC-32 detecta con certeza cualquier error de un solo bit y cualquier error en ráfaga de hasta 32 bits, lo que cubre prácticamente toda la corrupción accidental por ruido, degradación y fallos de transferencia. Lo que no puede hacer es establecer identidad frente a un adversario, porque un adversario puede construir una colisión a propósito en segundos. Si necesitas resistencia a colisiones, necesitas un hash criptográfico.

Calcula el CRC-32 del archivo aquí y compáralo con la suma que hayan registrado el responsable de la publicación o el sistema de transferencia. Si coinciden, el archivo llegó sin corrupción. Muchas herramientas ya lo hacen por ti, porque unzip verifica cada entrada, gzip y zlib verifican el final del flujo y los navegadores verifican los fragmentos PNG al decodificar, pero calcular el valor tú mismo es la forma más rápida de confirmar qué produjo una herramienta concreta, y es la única cuando tienes un formato inusual sin verificación integrada. Elige el modo File, selecciona la descarga y lee la salida CRC-32 of file. Una advertencia importante: que coincida el CRC-32 prueba que el archivo es el que generó quien lo publicó, solo si confías en esa persona. Si la descarga pudo ser manipulada en tránsito, un atacante con esa capacidad puede crear otro archivo con la misma suma, y por eso las publicaciones firmadas con GPG o firmas Sigstore existen junto a las sumas de verificación.

No. La calculadora es un componente de cliente: el JavaScript de tu navegador lee tu texto, tus bytes hexadecimales o el archivo que seleccionaste, construye la tabla CRC-32 en memoria y ejecuta el bucle de forma local. Nada se transmite por la red, nada se escribe en un registro de servidor y nada persiste después de cerrar la pestaña. Para el modo de archivo esto se implementa con la API de archivos del navegador, que lee el contenido del disco local bajo demanda. Esto tiene una ventaja práctica, no solo de privacidad: puedes comprobar una imagen de disco de varios gigabytes o un archivo confidencial regulado sin esperar a una subida y sin entregarle una copia de tus datos a un servicio de terceros.