CRC

A verificação cíclica de redundância (do inglês, CRC - Cyclic Redundancy Check) é um método de detecção de erros normalmente usada em redes digitais e dispositivos de armazenamento para detectar mudança acidental em cadeias de dados. Mensagens de dados entrando nesses sistemas recebem um pequeno anexo com um valor de verificação baseado no resto de divisão polinomial do seu conteúdo. No ato da recuperação do dado o cálculo é refeito e comparado com o valor gerado anteriormente. Se os valores não se mostrarem semelhantes podem ser aplicadas ações para correção de dados, evitando assim a corrupção de dados. CRC pode ser usada para correção de erros a partir de alguns métodos.

O nome CRC vem da redundância do valor de verificação atrelado ao dado (A mensagem recebe um aumento em seu tamanho sem adicionar uma informação) e o algoritmo de validação é construído com laços de repetição cíclicos.

A verificação cíclica de redundância é amplamente utilizada em dispositivos binários por ser de simples implementação, é matematicamente fácil de ser analisada e apresenta bons resultados na detecção de erros comuns em canais de transmissão causados por ruído. A função utilizada para gerar o valor de verificação possui tamanho fixo, e é utilizada igualmente como uma função hash.

O primeiro a propor a CRC foi W. Wesley Peterson em 1961. Hoje, a função CRC de 32 bits do Ethernet e vários outros padrões são trabalhos de vários pesquisadores e foi publicada em 1975.

Introdução

Verificação cíclica de redundância é baseada na teoria de códigos de correção de erros cíclicos. O uso de códigos cíclicos sistemáticos, que alteram a mensagem adicionando um valor de verificação de tamanho fixo, com o propósito de detecção de erros em redes de comunicação foi proposta por W. Wesley Peterson em 1961. Códigos cíclicos são simples de implementar e possuem o benefício apresentar ótimas respostas na detecção de erros causados pela “Rajada” de bits: sequencias continuas de símbolos de dados errados (Burst Errors).

Eles são importantes porque Burst Errors são ocorrências comuns em canais de comunicação, incluindo canais óticos ou magnéticos. Geralmente, um n-bit CRC aplicado sobre uma mensagem de tamanho qualquer irá detectar cada um desses erros que forem menores que n bits e uma fração de 1/(1- 2^(-n)) de bits em mensagens maiores.

A determinação de um valor para o código de validação requer a definição de um Gerador Polinomial.

Esse polinômio será o divisor em uma divisão polinomial em que a mensagem de dados será o dividendo e o quociente é descartado, porém o resto será o código de verificação. É importante mencionar que os coeficientes do gerador são calculados de acordo com a aritmética de campo finito, para que a operação de adição possa sempre ocorrer paralelamente bit-a-bit (sem carry entre dígitos).O tamanho do resto será sempre menor que o do gerador polinomial, com isso pode-se determinar o tamanho do código de verificação.

Na prática, a maioria dos códigos utilizam um campo Galois de 2 elementos, GF(2).Os elementos são geralmente chamados de 0 e 1 coincidentemente utilizados na arquitetura binária.

Um CRC é chamado de n-bit CRC quando seu código de verificação possui tamanho de n bits. Para um dado n, múltiplos códigos de verificação são possíveis de serem construídos, cada um com um polinômio diferente. Tal polinômio possui o maior grau de valor n, além de n + 1 termos. Ou seja, ele possui tamanho n + 1 bits.

Várias especificações descartam o MSB ou o LSB, pois eles sempre serão iguais a 1. Essas especificações serão encontradas mais a frente na forma de CRC-n-XXX.

O sistema de detecção de erro mais simples, o bit de paridade, é na verdade um 1-bit CRC, de polinômio x + 1 (dois termos), de nome CRC-1.

Aplicações

Um dispositivo que suporta CRC calcula uma pequena sequência binária de tamanho fixo, conhecido como código de verificação ou CRC, para cada mensagem que será enviada ou recebida e a anexa aos dados, formando uma palavra-código (codeword).

Quando uma palavra código é recebida ou lida, o dispositivo compara seu código de verificação anexado com um novo, calculado a partir da mensagem, ou aplica o CRC sobre toda a palavra-código e compara o resultado com uma constante residual pré-definida.

Se os códigos CRC não são semelhantes a mensagem contém erros de dados. O dispositivo pode realizar ações corretivas como reler a mensagem ou requisitar um novo envio da mesma.

Senão os dados podem ser tratados como corretos e sem erro. (Com uma pequena probabilidade o código pode conter erros não detectados; essa é a natureza fundamental da verificação de erros).

Integridade dos dados

Os códigos de verificação cíclica de redundância são projetados para proteger contra erros típicos dos canais de comunicação, onde podem garantir a integridade de mensagens de forma rápida e confiável. Entretanto, eles não são aplicáveis para proteção contra alteração intencional de dados.

Não há nenhum tipo de autenticação, um invasor pode editar a mensagem e recalcular seu código de verificação sem que a substituição seja detectada. Quando as funções criptográficas de hash e a CRC são armazenadas em conjunto com os dados, elas não podem proteger contra alterações intencionais dos dados. Aplicações que requerem tal proteção devem usar mecanismos de autenticação criptográficas como códigos de autenticação da mensagem ou assinaturas digitais.

Diferente das funções hash criptográficas , um CRC pode ser revertido facilmente, o que o torna inaplicável para uso com assinaturas digitais.

Finalmente, CRC são criados a partir de funções lineares, com a seguinte propriedade:$crc(x\oplus y\oplus z)=crc(x)\oplus crc(y)\oplus crc(z)$

Logo, mesmo que o CRC seja criptografado com uma cifra de fluxo (Stream cipher, um algoritmo de chave simétrica) que use a operação lógica OU exclusivo (XOR) como sua operação combinatória, ambas mensagem e CRC associada podem ser manipuladas sem o conhecimento da chave de manipulação. Essa era uma das falhas conhecidas do protocolo WEP.

Cálculo

Para calcular um CRC de n bits, coloque os bits representando o dado em uma linha, e abaixo do MSB dessa linha posicione o padrão (n + 1)-bit que representa o divisor CRC, também chamado de "polinômio".

Neste exemplo será utilizado uma mensagem de 14 bits, com um 3-bit CRC, e o polinômio gerador. O polinômio precisa ser escrito em binário, um polinômio de 3ª ordem possui 4 coeficientes (). Nesse caso, os coeficientes são: 1, 0, 1, 1. O resultado do cálculo tem 3 bits de tamanho.

A mensagem a ser codificada será:

11010011101100

Primeiro, são adicionados zeros no fim da palavra correspondentes ao tamanho n do CRC. Então é feito o primeiro cálculo para se obter o 3-bit CRC:

11010011101100 000 <--- entrada deslocada para a direita com 3 zeros
1011               <--- divisor (4 bits) = x³ + x + 1
------------------
01100011101100 000 <--- resultado

O algoritmo age sobre os bits diretamente acima do divisor em cada passo. O resultado para a iteração acima é a operação OU-exclusivo bit-a-bit para os bits acima do divisor polinomial. Os bits restantes são diretamente copiados para o resultado daquele passo. O Divisor é então deslocado para a direita em 1 bit e o processo é repetido até que divisor alcance o ultimo bit da mensagem. O cálculo completo pode ser visto a seguir:

11010011101100 000 <--- entrada deslocada para a direita com 3 zeros
1011               <--- divisor
01100011101100 000 <--- resultado (note que os primeiros 4 bits são um XOR com os bits acima do divisor, o resto é copiado).
 1011              <--- divisor ...
00111011101100 000
  1011
00010111101100 000
   1011
00000001101100 000 <--- note que o divisor irá se mover mais de 1 bit para se alinhar com o próximo bit 1 do dividendo (por que o quociente da operação para aquele passo seria 0). 
       1011             (Ou seja, ele não se move apenas 1 bit necessariamente.)
00000000110100 000
        1011
00000000011000 000
         1011
00000000001110 000
          1011
00000000000101 000
           101 1
-----------------
00000000000000 100 <--- resto (3 bits). O algoritmo de divisão para neste ponto pois o dividendo é zero.

Como o bit divisor mais à esquerda zerou todos os bits que interagiu, ao final desse processo apenas os n bits mais à direita da mensagem não serão zerados. Esses n bits correspondem ao resto da divisão polinomial, e ao valor da função CRC (a menos que a especificação do CRC escolhido exija algum processamento posterior).

A validade de uma mensagem recebida pode ser avaliada de maneira simples, aplicando o calculo acima novamente, porém o valor da função CRC será adicionado no lugar dos zeros à direita. O resto dessa operação deverá ser zero se nenhum erro for detectado.

11010011101100 100 <--- mensagem com o CRC
1011               <--- divisor
01100011101100 100 <--- resultado passo 1
 1011              <--- divisor ...
00111011101100 100

......

00000000001110 100
          1011
00000000000101 100
           101 1
------------------
00000000000000 000 <--- resto

Matemática

A análise matemática desse processo de “divisão” demonstra como selecionar um divisor que garantirá boas propriedades de detecção de erro. Nessa análise, os dígitos da linha de bits são utilizados como coeficientes de um polinômio em uma variável qualquer x (coeficientes que são na verdade elementos do campo finito de GF(2), ao invés de números quaisquer propriamente). Esse conjunto binário polinomial é um anel matemático.

Determinando polinômios

Selecionar o polinômio gerador é a parte mais importante de um algoritmo de verificação cíclica de redundância(CRC). O polinômio deve ser escolhido a fim de maximizar a capacidade de detecção de erros e minimizar a probabilidade de resultados semelhantes se utilizado outros polinômios.

O atributo mais importante do polinômio é seu tamanho (o maior grau de qualquer termo da expressão (maior expoente) + 1), pois isso impactará diretamente sobre o tamanho do valor de verificação.

Os tamanhos mais utilizados de polinômios são:

• 9 bits (CRC-8)
• 17 bits (CRC-16)
• 33 bits (CRC-32)
• 65 bits (CRC-64)

A determinação do polinômio de CRC depende do tamanho total da mensagem de dados a ser protegida (dados + bits de verificação CRC), das propriedades de proteção contra erros desejadas e da quantidade/tipo de recursos disponíveis para a implementação do CRC, além, é claro, da performance desejada. Um erro comum é assumir que os “melhores” polinômios para CRC são encontrados a partir de polinômios irredutíveis ou polinômios irredutíveis multiplicados pelo fator 1+x, que adiciona ao algoritmo a capacidade de detectar todos os erros que afetam um número ímpar de bits (1, 3, 5, ...).

Na realidade, todos os fatores descritos acima devem ser considerados para a escolha do polinômio e podem levar a um polinômio redutível. Entretanto, a escolha de um polinômio redutível irá causar um aumento na quantidade de erros que não serão detectados pelo CRC, pois o quociente do anel matemático terá divisores nulos.

A vantagem na escolha de um polinômio primitivo como gerador para um código CRC será encontrada no resultado que terá um tamanho total de mensagem tal que todos os erros de 1-bit contidos na mensagem terão restos da divisão distintos (chamados de síndromes) e por isso, o resto será uma função linear, e o algoritmo será capaz de detectar qualquer erro de 2 bits contidos na mensagem. Se $r$ é o grau do polinômio primitivo gerador, então o tamanho máximo da mensagem de dados será $2^{r}-1$ , e o código de verificação anexado será capaz de detectar qualquer erro de um bit ou de um par de bits.

Isso pode ser otimizado, se for utilizado um polinômio gerador $g(x)=p(x)(1+x)$, onde $p(x)$ é um polinômio primitivo de grau $r-1$ , então o tamanho máximo da mensagem será $2^{r-1}-1$, e o código se tornará capaz de detectar erros de bit único, duplo, triplo e qualquer conjunto de tamanho ímpar de bits.

O polinômio $g(x)$ admite que fatorações possam ser escolhidas para controlar o tamanho da mensagem com p poder de detecção de erros desejado. Os algoritmos de BCH são classes de tais polinômios. Eles incluem os dois exemplos acima. Independente das propriedades de redução de um gerador polinomial de grau , se ele é expresso com o termo “+1”, o código será capaz de detectar padrões de erro contidos em uma janela de bits contínuos. Esses padrões são chamados de “rajada de erros” (errors bursts). 

Especificação

O conceito da verificação cíclica de redundância como um algoritmo de detecção de erros ganha complexidade à medida que implementações ou comitês de normas à aplicam em sistemas reais. Alguns exemplos de complicações são:

• Algumas implementações usam um padrão de bits prefixado na linha dos dados a ser verificada. Isso é especialmente útil quando erros de temporização podem inserir bits de valor 0 antes da mensagem, essa alteração não iria alterar o código de verificação.
• Há uma chance da implementação anexar n bits de valor 0 (n sendo o tamanho do CRC) à linha de dados que será cerificada antes que a divisão polinomial ocorra. Esse tipo de anexação é demonstrada explicitamente no artigo Computation of CRC. É conveniente que o resto da linha de dados original com o valor de verificação anexado seja exatamente zero, para que a validade do CRC possa ser avaliada simplesmente efetuando a divisão polinomial dos dados recebidos e comparar o resto dessa operação com zero. Devido a propriedade associativa e comutativa da operação OU-exclusivo, implementações que utilizam tabelas de resultados para comparação podem obter um resultado numericamente equivalente a essa anexação de bits 0 sem ser necessário que ela aconteça, usando algum algoritmo equivalente [6] que combina os dados recebidos imediatamente com dados que acabaram de ser verificados, o tornando mais rápido.
• Padrões que implementam a operação OU-exclusivo em um número fixo de bits no resto da divisão polinomial.
• A ordem dos bits: algumas arquiteturas utilizam o bit de menor ordem de cada byte como o “primeiro” bit, que implica na divisão polinomial ser realizada a partir do bit mais à direita. Essa convenção é utilizada em transmissões via porta serial são validadas em hardware, admitindo-se que o bit menos significativo é transmitido primeiro.
• A ordem do byte: com CRC aplicado à múltiplos bytes pode haver confusão se o primeiro byte transmitido será o byte mais significativo ou o menos significativo. Algumas implementações 16-bit CRC trocam os bytes que devem ser avaliados pelo código de verificação.
• Omissão do bit mais significativo do divisor polinomial: como o bit de maior grau é sempre 1, e como um n-bit CRC é definido com o tamanho (n + 1) bits que é maior que um registro de n bits, alguns autores assumem que é desnecessário mencionar o bit de maior grau do divisor.
• Omissão do bit menos significativo do divisor polinomial: como o bit de menor grau é sempre 1, autores como Phillip Koopman representam polinômios com seu bit mais significativo intacto, porém o bit menos significativo ( o de termo $x^{0}$ ou 1 ) é descartado. Essa convenção representa o polinômio completo com seu grau em apenas uma variável inteira.

Essas complicações demonstram que um polinômio pode ser expresso de 3 formas diferentes: as duas primeiras são as mais encontradas em algoritmos, sendo que uma é a negação logica da outra; e a terceira é a forma encontrada nos artigos escritos por Koopman. Em cada caso, um termo é omitido. E o polinômio $x^{4}+x+1$ pode ser representado como:

• 0x3 = 0b0011, representando $x^{4}+(0x^{3}+0x^{2}+1x^{1}+1x^{0})$ (Com o bit mais significativo à esquerda)
• 0xC = 0b1100, representando $(1x^{0}+1x^{1}+0x^{2}+0x^{3})+x^{4}$ (Com o bit menos significativo à esquerda)
• 0x9 = 0b1001, representando $(1x^{4}+0x^{3}+0x^{2}+1x^{1})+x^{0}$ (notação utilizada por Koopman)

Na tabela abaixo eles são representados como:

Nome	Normal	Reversa	Reversa Reciproca
CRC-4	0x3	0xC	0x9

Padrões e Usos

Vários algoritmos de verificação cíclica de redundância são regidos por Normas Técnicas. Nenhum algoritmo, ou implementação de um polinômio de qualquer grau pode ser utilizado para todas as aplicações. Koopman e Chakravarty recomendam que a seleção de um polinômio seja feita de modo a atender as necessidades da aplicação e o tamanho esperado das mensagens enviadas. O número de algoritmos de CRC que podem ser usados gera certa confusão nos desenvolvedores, esse é o problema que a maioria de autores sobre o assunto busca resolver. Existem 3 polinômios utilizados para o CRC-12, 19 conflitos nas definições para o CRC-16, e 7 para o CRC-32. 

Os polinômios que são utilizados não são necessariamente os mais eficientes. Desde 1993, Koopman, Castagnoli e outros trabalharam com a abrangência de polinômios entre 3 e 64 bits de comprimento,  buscando exemplos que possuíam uma melhora na performance (em termos da Distância de Hamming para determinado tamanho de mensagem) em comparação com os polinômios utilizados em padrões anteriores, publicando os que apresentavam melhores resultados com o intuito de otimizar a capacidade de detecção de erros de padrões futuros.  Em particular, o iSCSI e SCTP utilizam um dos polinômios descobertos durante a pesquisa, o polinômio (Castagnoli) CRC-32C.

O projeto do polinômio de 32 bits utilizado na maioria dos padrões, o CRC-32-IEEE, foi resultado de um esforço conjunto para Laboratório Rome e a Divisão de Sistemas Eletrônicos das Forças Aéreas americanas obtido por Joseph Hammond, James Brown, Shyan-Shiang Liu, do Instituto de Tecnologia da Georgia, e Kenneth Brayer da Corporação MITRE.

As primeiras publicações sobre o polinômio de 32 bits ocorreram em 1975: no Relatório Técnico 2956 da Corporação MITRE, publicado internamente em Janeiro e divulgado para o público em Agosto pelo DTIC, além do relatório de Hammond, Brown e Liu para o laboratório de Roma publicado em Maio. Ambos os relatórios continham contribuições das equipes envolvidas. Em Dezembro de 1975, Brayer e Hammond apresentaram um artigo com informações sobre seu trabalho na Conferência Nacional de Telecomunicações IEEE: o CRC-32-IEE é o polinômio gerado a partir de um código Hamming e foi escolhido pela sua performance na detecção de erros.  No entanto, o polinômio CRC-32C de Castagnoli usado nos protocolos iSCSI ou SCTP apresenta o mesmo desempenho para mensagens com o tamanho entre 58 bits a 131k bits, e um desempenho superior para diferentes tamanhos de mensagens, incluindo os e tamanhos de pacotes mais utilizados pela internet. O padrão ITU-T G.hn também faz uso do CRC-32C para detectar erros nos dados( entretanto ele utiliza o CRC-16-CCITT para outras aplicações).

A tabela abaixo lista apenas polinômios de vários algoritmos que estão em uso. Variações particulares dos protocolos podem utilizar pré-inversão, pós-inversão e ordenação reversa de bits como descrito acima. Por exemplo, o CRC32 utilizado nos padrões Gzip e Bzip2 utilizam o mesmo polinômio, porém o Gzip aplica a ordenação reversa de bits.

CRCs de protocolos proprietários podem utilizar valores iniciais não triviais e um operação XOR adicional para esconder seu valor, mas tais técnicas não aumentam a força da criptografia utilizada no algoritmo e podem ser desmascaradas utilizando métodos diretos de engenharia reversa.

Nome	Uso	Polynomial representations
		Normal	Reversa	Reversa Reciproca
CRC-1	Maioria em hardware;conhecido como parity bit	0x1	0x1	0x1
CRC-3-GSM	redes móveis	0x3	0x6	0x5
CRC-4-ITU	G.704	0x3	0xC	0x9
CRC-5-EPC	Gen 2 RFID	0x09	0x12	0x14
CRC-5-ITU	G.704	0x15	0x15	0x1A
CRC-5-USB	USB pacotes de token	0x05	0x14	0x12
CRC-6-CDMA2000-A	redes móveis	0x27	0x39	0x33
CRC-6-CDMA2000-B	redes móveis	0x07	0x38	0x23
CRC-6-DARC	Canal de Dados via Rádio	0x19	0x26	0x2C
CRC-6-GSM	redes móveis	0x2F	0x3D	0x37
CRC-6-ITU	G.704	0x03	0x30	0x21
CRC-7	sistemas de telecomunicação, G.707, G.832, MMC, SD	0x09	0x48	0x44
CRC-7-MVB	Rede de Comunicação Ferroviária, IEC 60870-5	0x65	0x53	0x72
CRC-8	DVB-S2	0xD5	0xAB	0xEA
CRC-8-AUTOSAR	Integração Automotiva, OpenSafety	0x2F	0xF4	0x97
CRC-8-Bluetooth	Conectividade Wireless	0xA7	0xE5	0xD3
CRC-8-CCITT	I.432.1; ATM HEC, ISDN HEC e fronteiras de células	0x07	0xE0	0x83
CRC-8-Dallas/Maxim	1-Wire bus	0x31	0x8C	0x98
CRC-8-DARC	Canal de Dados via Rádio	0x39	0x9C	0x9C
CRC-8-GSM-B	redes móveis	0x49	0x92	0xA4
CRC-8-SAE J1850	AES3	0x1D	0xB8	0x8E
CRC-8-WCDMA	redes móveis	0x9B	0xD9	0xCD
CRC-10	ATM; I.610	0x233	0x331	0x319
CRC-10-CDMA2000	redes móveis	0x3D9	0x26F	0x3EC
CRC-10-GSM	redes móveis	0x175	0x2BA	0x2BA
CRC-11	FlexRay	0x385	0x50E	0x5C2
CRC-12	sistemas de telecomunicação	0x80F	0xF01	0xC07
CRC-12-CDMA2000	redes móveis	0xF13	0xC8F	0xF89
CRC-12-GSM	redes móveis	0xD31	0x8CB	0xE98
CRC-13-BBC	Sinal Temporizado, Radio teleswitch	0x1CF5	0x15E7	0x1E7A
CRC-14-DARC	Canal de Dados via Rádio	0x0805	0x2804	0x2402
CRC-14-GSM	redes móveis	0x202D	0x2D01	0x3016
CRC-15-CAN		0x4599	0x4CD1	0x62CC
CRC-15-MPT1327		0x6815	0x540B	0x740A
CRC-16-Chakravarty	Otimizado para mensagens ≤64 bits	0x2F15	0xA8F4	0x978A
CRC-16-ARINC	ACARS aplicações	0xA02B	0xD405	0xD015
CRC-16-CCITT	X.25, V.41, HDLC FCS, XMODEM, Bluetooth, PACTOR, SD, DigRF, Vários outros; conhecido como CRC-CCITT	0x1021	0x8408	0x8810
CRC-16-CDMA2000	redes móveis	0xC867	0xE613	0xE433
CRC-16-DECT	Telefones Sem Fio	0x0589	0x91A0	0x82C4
CRC-16-T10-DIF	SCSI DIF	0x8BB7	0xEDD1	0xC5DB
CRC-16-DNP	DNP, IEC 870, M-Bus	0x3D65	0xA6BC	0x9EB2
CRC-16-IBM	Bisync, Modbus, USB, ANSI X3.28, SIA DC-07, Vários outros; também conhecido como CRC-16 e CRC-16-ANSI	0x8005	0xA001	0xC002
CRC-16-OpenSafety-A	bateria de testes seguros	0x5935	0xAC9A	0xAC9A
CRC-16-OpenSafety-B	bateria de testes seguros	0x755B	0xDAAE	0xBAAD
CRC-16-Profibus	redes de testes seguros	0x1DCF	0xF3B8	0x8EE7
CRC-17-CAN	CAN FD	0x1685B	0x1B42D	0x1B42D
CRC-21-CAN	CAN FD	0x102899	0x132281	0x18144C
CRC-24	FlexRay	0x5D6DCB	0xD3B6BA	0xAEB6E5
CRC-24-Radix-64	OpenPGP, RTCM104v3	0x864CFB	0xDF3261	0xC3267D
CRC-30	CDMA	0x2030B9C7	0x38E74301	0x30185CE3
CRC-32	HDLC, ANSI X3.66 (ADCCP), ITU-T V.42, ISO/IEC/IEEE 8802-3 (Ethernet), Serial ATA, MPEG-2, PKZIP, Gzip, Bzip2, POSIX cksum, PNG, Vários outros	0x04C11DB7	0xEDB88320	0x82608EDB
CRC-32C (Castagnoli)	iSCSI, SCTP, G.hn payload, SSE4.2, Btrfs, ext4, Ceph	0x1EDC6F41	0x82F63B78	0x8F6E37A0
CRC-32K (Koopman {1,3,28})		0x741B8CD7	0xEB31D82E	0xBA0DC66B
CRC-32K2 (Koopman {1,1,30})		0x32583499	0x992C1A4C	0x992C1A4C
CRC-32Q	aviação; AIXM	0x814141AB	0xD5828281	0xC0A0A0D5
CRC-40-GSM	Canal de Controle GSM	0x0004820009	0x9000412000	0x8002410004
CRC-64-ECMA	ECMA-182, XZ Utils	0x42F0E1EBA9EA3693	0xC96C5795D7870F42	0xA17870F5D4F51B49
CRC-64-ISO	HDLC, Swiss-Prot/TrEMBL; considerado fraco para hashing	0x000000000000001B	0xD800000000000000	0x800000000000000D

Ver também

• Detecção e correção de erros#Redundância cíclica (CRC)

Ligações externas

Predefinição:Refbegin*Almeida, Rodrigo Maximiano Antunes de (Dezembro de 2013). «Troca de contexto segura em sistemas operacionais embarcados utilizando técnicas de detecção e correção de erros» (PDF) Exemplos e análises sobre o comportamento de códigos CRC e de Hamming aplicado à embarcados

• Mitra, Jubin; Nayak, Tapan (Janeiro de 2017). «Reconfigurable very high throughput low latency VLSI (FPGA) design architecture of CRC 32». Integration, the VLSI Journal. 56: 1–14. doi:10.1016/j.vlsi.2016.09.005 
• Cyclic Redundancy Checks, MathPages, visão geral da detecção de erro de alguns polinômios
• Williams, Ross (1993). «A Painless Guide to CRC Error Detection Algorithms». The Blue Book. Systems Research Group, Computer Laboratory, University of Cambridge 
• Black, Richard (1994). «Fast CRC32 in Software». The Blue Book algoritmo 4 é usado em Linux e Bzip2.
• Kounavis, M.; Berry, F. (2005). «A Systematic Approach to Building High Performance, Software-based, CRC generators» (PDF). Intel , algoritmos de corte por 4 e 8 *Kowalk, W. (Agosto de 2006). «CRC Cyclic Redundancy Check Analysing and Correcting Errors» (PDF). Universität Oldenburg  — filtros de bit
• Warren, Henry S., Jr. «Cyclic Redundancy Check» (PDF). Hacker's Delight (PDF). [S.l.: s.n.]  — teoria, prática, hardware e software com enfase no CRC-32.
• Reverse-Engineering a CRC Algorithm
• Cook, Greg. «Catalogue of parameterised CRC algorithms». CRC RevEng 
• Koopman, Phil. «Blog: Checksum and CRC Central»  — inclui links para PDFs sobre 16 e 32-bit CRC Distância de Hamming
• Koopman, Philip; Driscoll, Kevin; Hall, Brendan (Março de 2015). «Cyclic Redundancy Code and Checksum Algorithms to Ensure Critical Data Integrity» (PDF). Federal Aviation Administration. DOT/FAA/TC-14/49 

Ver também

• Tolerância a Falhas
• Falha (computação)
• TMR