As linhas usam a forma “ALGORITMO valor” seguida de uma linha de parâmetros com recuo, pelo que um resultado copiado e colado indica sempre qual o conjunto de parâmetros que o produziu.
CRC — verificação por redundância cíclica, explicada do zero
Numa frase: um CRC trata os seus dados como um número binário gigante, divide-o por um número “gerador” fixo usando XOR em vez de subtração, e devolve o resto — uma impressão digital compacta que muda drasticamente quando se inverte sequer um bit da entrada, razão pela qual tudo, desde os ficheiros PNG aos fios Modbus, o transporta.
O que é, na prática, um CRC
A imagem da divisão. Alinhe os seus bytes como um único número binário longo. Escolha um divisor — o polinómio, por exemplo 0x04C11DB7 para CRC-32. Execute uma divisão binária longa em que a “subtração” é a operação XOR: sempre que o bit mais significativo do resto corrente for 1, faça XOR com o divisor, desloque para a esquerda e repita. Quando toda a mensagem tiver passado, o que sobra no registo é o CRC. Sem chaves, sem tabelas na definição — apenas uma divisão com resto.
Os cinco parâmetros. Dois sistemas podem ambos dizer “CRC-32” e ainda assim discordar, porque o nome sozinho não fixa nada. A receita completa precisa de cinco valores: poly (o divisor), init (com que valor o registo começa — zeros tornam invisíveis os bytes zero iniciais, uns não), refin/refout (se cada byte de entrada — e o registo final — é invertido bit a bit, herança do hardware série, que enviava os bits do menos significativo para o mais significativo), e xorout (uma máscara XOR final para que uma sequência de zeros no fim ainda altere o resultado). Esta página imprime os cinco ao lado de cada resultado precisamente por isso.
Porque é que deteta erros. Um divisor bem escolhido faz com que o resto de uma mensagem e o resto da mesma mensagem com alguns bits invertidos difiram com probabilidade esmagadora: um bom CRC-32 apanha todos os erros de 1 e 2 bits, todos os números ímpares de erros de bit e todas as rajadas de até 32 bits consecutivos corrompidos — garantido, e não probabilisticamente. Essa garantia diz respeito à corrupção acidental, e é o que torna os CRCs a ferramenta certa para fios ruidosos e discos instáveis.
O que um CRC não é
Não é um hash criptográfico. Não há segredo nem unidirecionalidade: quem conhecer os parâmetros pode forjar uma mensagem com qualquer CRC que queira, em milissegundos, acrescentando quatro bytes de correção. Um CRC deteta acidentes, nunca adversários. Para transferências que verifica contra terceiros, as assinaturas são o que conta — veja em vez disso o Gerador de hash (MD5/SHA/BLAKE2). Essa página também explica porque é que MD5 e SHA-1 estão retirados para cenários hostis, enquanto o SHA-256 se mantém.
Não é um código de correção de erros. Um CRC diz-lhe que algo mudou, não o que mudou. Reparar erros em tempo real é a tarefa de códigos como Reed–Solomon ou Hamming, que armazenam deliberadamente uma estrutura redundante que um descodificador consegue inverter.
Não é compressão nem cifragem. O resto tem poucos bytes qualquer que seja o tamanho da entrada, e a partir dele não se recupera a entrada — mas, ao contrário de um hash criptográfico, isso acontece apenas porque a informação foi descartada, e não porque a inversão seja difícil.
As famílias desta página
Os quádruplos CRC-32. Quatro entradas desta página partilham o polinómio 0x04C11DB7 e ainda assim produzem valores diferentes: ISO-HDLC (refletido, init/xorout todos a uns) é “o” CRC-32 do zlib, gzip, PNG e ZIP; BZIP2 é a mesma matemática não refletida; MPEG-2 é o BZIP2 sem XOR final; POSIX começa em zero e é a base do comando cksum (que, além disso, acrescenta o comprimento do ficheiro à divisão, pelo que o cksum de um ficheiro e o CRC-32/POSIX dos mesmos bytes diferem). O CRC-32C (Castagnoli, polinómio 0x1EDC6F41) é o quinto irmão: um polinómio diferente, escolhido para melhor desempenho na deteção de erros, e o que os CPUs x86 e ARM modernos conseguem calcular à velocidade da memória com uma única instrução.
O quarteto CRC-64. XZ usa o polinómio ECMA-182 em forma refletida, com init e xorout todos a uns; o ECMA-182 em si é o original não refletido, com init zero, da norma de fita DLT-1; GO-ISO é o crc64.ISO do Go, um polinómio minúsculo 0x1B, ainda refletido; REDIS usa um polinómio escolhido por um bom efeito de avalanche na atribuição de slots de hash. Sessenta e quatro bits é a dimensão a partir da qual os CRCs começam a ser usados como funções de hash (distribuição em baldes) e não apenas como somas de verificação puras.
Adler-32 é o intruso: não é de todo uma divisão. Soma os bytes (A, começando em 1) e soma essas somas (B), ambas módulo 65521, e concatena as duas somas de 16 bits. É mais rápido do que CRC-32 em software, e o zlib usa-o para os fluxos deflate — mas para entradas curtas (menos de algumas centenas de bytes) a soma transporta informação insuficiente, e é exatamente por isso que o zlib volta ao CRC-32 para blocos pequenos.
CRC-8 e CRC-16 sobrevivem onde os bytes são caros: o CRC-8/CCITT (polinómio 0x07) protege bytes isolados de cabeçalho no SMBus e em protocolos de rádio celular; o CRC-16/CCITT-FALSE protege blocos de cartões inteligentes; o CRC-16/MODBUS é a soma de verificação de cada trama Modbus RTU em fábricas de todo o mundo.
Onde é usado cada um
| Conjunto de parâmetros | Encontrado em |
|---|
| CRC-32/ISO-HDLC | zlib, gzip, PNG, ZIP, Ethernet (FCS), muitos formatos de arquivo |
| CRC-32C | iSCSI, ext4, btrfs, ZFS, instrução de hardware CRC32C do SSE4.2/ARMv8 |
| CRC-32/BZIP2 | fluxo de arquivo .bz2 |
| CRC-32/MPEG-2 | fluxos de transporte MPEG-2 |
| CRC-32/POSIX & cksum | saída do comando POSIX cksum (cksum ficheiro.txt) |
| CRC-16/MODBUS | tramas Modbus RTU (PLC industriais, contadores, inversores) |
| CRC-16/CCITT-FALSE | cartões inteligentes, ligações próximas de X.25, alguns protocolos GPS |
| CRC-8/CCITT | SMBus (byte PEC), cabeçalhos de rádio celular |
| CRC-64/XZ | verificações de integridade de contentores .xz |
| CRC-64/ECMA-182 | ECMA-182 / norma de fita DLT-1 |
| CRC-64/GO-ISO | Biblioteca padrão do Go crc64.ISO |
| CRC-64/REDIS | Atribuição de slots de hash do cluster Redis |
| Adler-32 | fluxos zlib (deflate), outros contextos de somas de verificação rápidas |
A tabela de âncoras — check(“123456789”)
A convenção do catálogo CRC é publicar o resultado para a cadeia ASCII 123456789 (9 bytes). Todos os valores abaixo são reproduzíveis nesta página: escreva 123456789 na caixa de texto, marque o algoritmo e clique em Calcular.
| Conjunto de parâmetros | Largura | Valor de verificação (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 |
Fontes: cada valor foi validado de forma cruzada por uma implementação bit a bit de referência independente e, quando existe, contra a biblioteca do sistema que traz o algoritmo (zlib para CRC-32 e Adler-32; o catálogo CRC de Greg Cook para os restantes).
Erros comuns
- “CRC-32” sem parâmetros. Entre ISO-HDLC, BZIP2, MPEG-2, POSIX e CRC-32C, circulam cinco valores diferentes com o mesmo nome. Registe sempre poly/init/refin/refout/xorout juntamente com o resultado — esta página imprime-os por si.
- Comparar o CRC-32 de um ficheiro com a saída de
cksum. Algoritmos diferentes: cksum acrescenta o comprimento e usa um init diferente. Os números não coincidirão, e ambos estão “certos”.
- Confiar no CRC contra adulteração. Forjar um CRC coincidente é um exercício clássico (corrigir os últimos 4 bytes). Use um MAC com chave (HMAC) ou uma assinatura quando a outra parte possa ser hostil.
- Esperar efeito de avalanche. Um CRC é linear: mensagens relacionadas dão CRCs relacionados. Serve para ruído, mas não para hash — se precisar de distribuir em baldes, CRC-64 ou um hash real é mais seguro do que CRC-32.
- Texto hex contra bytes. A cadeia
"123456789" (9 bytes ASCII, 31 32 33 34 35 36 37 38 39) e o número 0x123456789 são entradas diferentes, com CRCs diferentes. Use o separador Bytes hex quando os dados de origem forem realmente binários.
Perguntas frequentes
Porque é que o meu CRC-32 não coincide com o do ficheiro ZIP? O CRC-32 do ZIP é o ISO-HDLC sobre os dados descomprimidos. Certifique-se de que calculou o hash sobre os mesmos bytes (não sobre o fluxo comprimido), no mesmo modo (Texto ou Hex) e com o mesmo conjunto de parâmetros — a linha de parâmetros impressa por baixo de cada resultado existe para tornar essa verificação imediata.
Qual é melhor, CRC-32C ou CRC-32? Para deteção de erros acidentais, ambos apanham todas as rajadas até 32 bits; o CRC-32C tem melhor desempenho em alguns padrões de erro e é o que tem instruções no CPU — praticamente gratuito a velocidades de gigabit. A razão pela qual o CRC-32/ISO-HDLC continua em uso é a compatibilidade: trinta anos de arquivos falam essa linguagem.
O CRC-64 é mais forte do que o CRC-32? Deteta rajadas mais longas (até 64 bits) e colide muito menos quando usado para distribuição em baldes, mas é igualmente forjável — a largura compra garantias de deteção, não segurança.
É possível inverter um CRC para revelar a entrada? Não — infinitas entradas partilham um mesmo CRC. Mas, ao contrário de um hash criptográfico, um atacante pode construir uma entrada com qualquer CRC que escolha, e é nesse sentido que não é de todo unidirecional.
