CRC

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa


Verificação Cíclica de Redundância (CRC)[editar | editar código-fonte]

Ver artigo principal: Cyclic redundancy check

         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 dedados. CRC pode ser usada para correção de erros a partir de alguns métodos.[1]

           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 32-bit CRC function of Ethernet e vários outros padrões são trabalhos de vários pesquisadores e foi publicada em 1975.

Introdução[editar | editar código-fonte]

           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.[2] 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 por que 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 polinomial 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 ode 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[editar | editar código-fonte]

            Um dispositivo CRC-enabled calcula uma pequena sequencia binária de tamanho fixo, conhecido como código de verificação ou CRC, para cada mensagem 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 ).[3]

Integridade dos dados[editar | editar código-fonte]

           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 evitar 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 de criptografia , um CRC pode ser revertido facilmente, o que o torna inaplicável para uso com assinaturas digitais. [4]

            Finalmente, CRC são criados a partir de funções lineares, com a seguinte propriedade:

            Logo, mesmo que o CRC seja encriptado com um 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. [5]

Cálculo[editar | editar código-fonte]

            Para calcular um n-bit CRC, 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 "polynomial".

            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). Ou seja, ele não se move apenas 1 bit necessariamente.
       1011
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
------------------
               0 <--- resto

Matemática[editar | editar código-fonte]

            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[editar | editar código-fonte]

            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 polinomial 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 polinomiais irredutíveis ou polinomiais 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, ...).[6]

           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   é o grau do polinômio primitivo gerador, então o tamanho máximo da mensagem de dados será , e o código de verificação anexado será capaz de detectar qualquer erro de um bit ou de um par de bits.[7]

           Isso pode ser otimizado, se for utilizado um polinômio gerador , onde  é um polinômio primitivo de grau , então o tamanho máximo da mensagem será , 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  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[editar | editar código-fonte]

            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 polinomiais com seu bit mais significativo intacto, porém o bit menos significativo ( o de termo ou 1 ) é descartado. Essa convenção representa o polinomial completo com seu grau em apenas uma variável inteira.

            Essas complicações demonstram que um polinomial 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 polinomial  pode ser representado como:

  • 0x3 = 0b0011, representando  (Com o bit mais significativo à esquerda)
  • 0xC = 0b1100, representando  (Com o bit menos significativo à esquerda)
  • 0x9 = 0b1001, representando  (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[editar | editar código-fonte]

            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.[8] 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.[6] Existem 3 polinômios utilizados para o CRC-12,[8] 19 conflitos nas definições para o CRC-16, e 7 para o CRC-32. [9]

            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, [8][10][11][12] 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. [11] 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,[13] além do relatório de Hammond, Brown e Liu para o laboratório de Roma publicado em Maio. [14]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. [15] 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.[11] 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.[9]

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.[16]

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[17] 0x3 0x6 0x5
CRC-4-ITU G.704 0x3 0xC 0x9
CRC-5-EPC Gen 2 RFID[18] 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[19] 0x27 0x39 0x33
CRC-6-CDMA2000-B redes móveis[19] 0x07 0x38 0x23
CRC-6-DARC Canal de Dados via Rádio[20] 0x19 0x26 0x2C
CRC-6-GSM redes móveis[17] 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[21] 0x65 0x53 0x72
CRC-8 DVB-S2[22] 0xD5 0xAB 0xEA[23]
CRC-8-AUTOSAR Integração Automotiva,[24] OpenSafety[25] 0x2F 0xF4 0x97[23]
CRC-8-Bluetooth Conectividade Wireless[26] 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[20] 0x39 0x9C 0x9C
CRC-8-GSM-B redes móveis[17] 0x49 0x92 0xA4
CRC-8-SAE J1850 AES3 0x1D 0xB8 0x8E
CRC-8-WCDMA redes móveis[19][27] 0x9B 0xD9 0xCD[23]
CRC-10 ATM; I.610 0x233 0x331 0x319
CRC-10-CDMA2000 redes móveis[19] 0x3D9 0x26F 0x3EC
CRC-10-GSM redes móveis[17] 0x175 0x2BA 0x2BA
CRC-11 FlexRay[28] 0x385 0x50E 0x5C2
CRC-12 sistemas de telecomunicação[29][30] 0x80F 0xF01 0xC07[23]
CRC-12-CDMA2000 redes móveis[19] 0xF13 0xC8F 0xF89
CRC-12-GSM redes móveis[17] 0xD31 0x8CB 0xE98
CRC-13-BBC Sinal Temporizado, Radio teleswitch[31] 0x1CF5 0x15E7 0x1E7A
CRC-14-DARC Canal de Dados via Rádio[20] 0x0805 0x2804 0x2402
CRC-14-GSM redes móveis[17] 0x202D 0x2D01 0x3016
CRC-15-CAN 0x4599[32][33] 0x4CD1 0x62CC
CRC-15-MPT1327 [34] 0x6815 0x540B 0x740A
CRC-16-Chakravarty Otimizado para mensagens ≤64 bits[21] 0x2F15 0xA8F4 0x978A
CRC-16-ARINC ACARS aplicações[35] 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[23]
CRC-16-CDMA2000 redes móveis[19] 0xC867 0xE613 0xE433
CRC-16-DECT Telefones Sem Fio[36] 0x0589 0x91A0 0x82C4
CRC-16-T10-DIF SCSI DIF 0x8BB7[37] 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; also conhecido como CRC-16 e CRC-16-ANSI 0x8005 0xA001 0xC002
CRC-16-OpenSafety-A bateria de testes seguros[25] 0x5935 0xAC9A 0xAC9A[23]
CRC-16-OpenSafety-B bateria de testes seguros[25] 0x755B 0xDAAE 0xBAAD[23]
CRC-16-Profibus redes de testes seguros[38] 0x1DCF 0xF3B8 0x8EE7
CRC-17-CAN CAN FD[39] 0x1685B 0x1B42D 0x1B42D
CRC-21-CAN CAN FD[39] 0x102899 0x132281 0x18144C
CRC-24 FlexRay[28] 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,[40] PNG,[41] Vários outros 0x04C11DB7 0xEDB88320 0x82608EDB[42]
CRC-32C (Castagnoli) iSCSI, SCTP, G.hn payload, SSE4.2, Btrfs, ext4, Ceph 0x1EDC6F41 0x82F63B78 0x8F6E37A0[42]
CRC-32K (Koopman {1,3,28}) 0x741B8CD7 0xEB31D82E 0xBA0DC66B[42]
CRC-32K2 (Koopman {1,1,30}) 0x32583499 0x992C1A4C 0x992C1A4C[42]
CRC-32Q aviação; AIXM[43] 0x814141AB 0xD5828281 0xC0A0A0D5
CRC-40-GSM Canal de Controle GSM[44][45] 0x0004820009 0x9000412000 0x8002410004
CRC-64-ECMA ECMA-182, XZ Utils 0x42F0E1EBA9EA3693 0xC96C5795D7870F42 0xA17870F5D4F51B49
CRC-64-ISO HDLC, Swiss-Prot/TrEMBL; considerado fraco para hashing[46] 0x000000000000001B 0xD800000000000000 0x800000000000000D

Ver também[editar | editar código-fonte]

Referências[editar | editar código-fonte]

  1. http://www.drdobbs.com/an-algorithm-for-error-correcting-cyclic/184401662  Em falta ou vazio |título= (ajuda)
  2. Peterson;Brown, W.W.;D.T (Janeiro de 1961). «Cyclic Codes for Error Detection». Proceedings of the IRE. 49 (1): 228–235. doi:10.1109/JRPROC.1961.287814 
  3. Ritter, Terry (Fevereiro de 1986). «The Great CRC Mystery». Dr. Dobb's Journal. 11 (2): 26-34, 76-83. Consultado em 5 de setembro de 2017 
  4. Stigge, Martin; Plötz, Henryk; Müller, Wolf; Jens-Peter, Jens-Peter (Maio de 2006). «Reversing CRC – Theory and Practice» (PDF). 17 páginas. Consultado em 6 de setembro de 2017 
  5. Cam-Winget, Nancy; Housley, Russ; Wagner, David; Walker, Jesse (Maio de 2003). «Security Flaws in 802.11 Data Link Protocols». Communications of the ACM. 46 (5): 35–39. doi:10.1145/769800.769823 
  6. a b Williams, Ross N. (24 de setembro de 1996). «A Painless Guide to CRC Error Detection Algorithms V3.0». Consultado em 5 de junho de 2010 
  7. Press, WH; Teukolsky, SA; Vetterling, WT; Flannery, BP (2007). «Section 22.4 Cyclic Redundancy and Other Checksums». Numerical Recipes: The Art of Scientific Computing 3rd ed. New York: Cambridge University Press. ISBN 978-0-521-88068-8 
  8. a b c Koopman, Philip; Chakravarty, Tridib (junho de 2004). «Cyclic Redundancy Code (CRC) Polynomial Selection For Embedded Networks» (PDF). The International Conference on Dependable Systems and Networks: 145–154. ISBN 0-7695-2052-9. doi:10.1109/DSN.2004.1311885. Consultado em 14 de janeiro de 2011 
  9. a b Cook, Greg (27 de julho de 2016). «Catalogue of parametrised CRC algorithms». Consultado em 1 de agosto de 2016 
  10. Castagnoli, G.; Bräuer, S.; Herrmann, M. (junho de 1993). «Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits». IEEE Transactions on Communications. 41 (6): 883–892. doi:10.1109/26.231911 
  11. a b c Koopman, Philip (julho de 2002). «32-Bit Cyclic Redundancy Codes for Internet Applications» (PDF). The International Conference on Dependable Systems and Networks: 459–468. ISBN 0-7695-1597-5. doi:10.1109/DSN.2002.1028931. Consultado em 14 de janeiro de 2011 
  12. Koopman, Philip (21 de janeiro de 2016). «Best CRC Polynomials». Pittsburgh: Carnegie Mellon University. Consultado em 26 de janeiro de 2016 
  13. Brayer, Kenneth (agosto de 1975). «Evaluation of 32 Degree Polynomials in Error Detection on the SATIN IV Autovon Error Patterns». National Technical Information Service: 74. Consultado em 3 de fevereiro de 2011 
  14. Hammond, Joseph L., Jr.; Brown, James E.; Liu, Shyan-Shiang (1975). «Development of a Transmission Error Model and an Error Control Model» (PDF). National Technical Information Service (publicado em maio de 1975). Unknown. 76: 74. Bibcode:1975STIN...7615344H. Consultado em 7 de julho de 2012 
  15. Brayer, Kenneth; Hammond, Joseph L., Jr. (dezembro de 1975). «Evaluation of error detection polynomial performance on the AUTOVON channel». Conference Record. IEEE National Telecommunications Conference, New Orleans, La. 1. New York: Institute of Electrical and Electronics Engineers. pp. 8–21 to 8–25. Bibcode:1975ntc.....1....8B 
  16. Ewing, Gregory C. (março de 2010). «Reverse-Engineering a CRC Algorithm». Christchurch: University of Canterbury. Consultado em 26 de julho de 2011 
  17. a b c d e f ETSI TS 100 909 (PDF). Col: V8.9.0. Sophia Antipolis, France: European Telecommunications Standards Institute. Janeiro de 2005. Consultado em 21 de outubro de 2016 
  18. Class-1 Generation-2 UHF RFID Protocol (PDF). Col: 1.2.0. [S.l.]: EPCglobal. 23 de outubro de 2008. p. 35. Consultado em 4 de julho de 2012  (Table 6.12)
  19. a b c d e f Physical layer standard for cdma2000 spread spectrum systems (PDF). Col: Revision D version 2.0. [S.l.]: 3rd Generation Partnership Project 2. Outubro de 2005. pp. 2–89–2–92. Consultado em 14 de outubro de 2013 
  20. a b c ETSI EN 300 751 (PDF). Col: V1.2.1. Sophia Antipolis, France: European Telecommunications Standards Institute. Janeiro de 2003. pp. 67–8. Consultado em 26 de janeiro de 2016 
  21. a b Chakravarty, Tridib (dezembro de 2001). Performance of Cyclic Redundancy Codes for Embedded Networks (PDF) (Tese). Pittsburgh: Carnegie Mellon University. pp. 5,18. Consultado em 8 de julho de 2013 
  22. EN 302 307 (PDF). Col: V1.3.1. Sophia Antipolis, France: European Telecommunications Standards Institute. Março de 2013. p. 17. Consultado em 29 de julho de 2016 
  23. a b c d e f g Koopman, Philip; Chakravarty, Tridib (junho de 2004). «Cyclic Redundancy Code (CRC) Polynomial Selection For Embedded Networks» (PDF). The International Conference on Dependable Systems and Networks: 145–154. ISBN 0-7695-2052-9. doi:10.1109/DSN.2004.1311885. Consultado em 14 de janeiro de 2011 
  24. Specification of CRC Routines (PDF). Col: 4.2.2. Munich: AUTOSAR. 22 de julho de 2015. p. 24. Consultado em 24 de julho de 2016 
  25. a b c openSAFETY Safety Profile Specification: EPSG Working Draft Proposal 304. Col: 1.4.0. Berlin: Ethernet POWERLINK Standardisation Group. 13 de março de 2013. p. 42. Consultado em 22 de julho de 2016 
  26. Specification of the Bluetooth System. 2. [S.l.]: Bluetooth SIG. 2 de dezembro de 2014. pp. 144–5. Consultado em 20 de outubro de 2014 
  27. Richardson, Andrew (17 de março de 2005). WCDMA Handbook. Cambridge, UK: Cambridge University Press. p. 223. ISBN 0-521-82815-5 
  28. a b FlexRay Protocol Specification. Col: 3.0.1. [S.l.]: Flexray Consortium. Outubro de 2010. p. 114  (4.2.8 Header CRC (11 bits))
  29. Perez, A. (1983). «Byte-Wise CRC Calculations». IEEE Micro. 3 (3): 40–50. doi:10.1109/MM.1983.291120 
  30. Ramabadran, T.V.; Gaitonde, S.S. (1988). «A tutorial on CRC computations». IEEE Micro. 8 (4): 62–75. doi:10.1109/40.7773 
  31. Ely, S.R.; Wright, D.T. (março de 1982). L.F. Radio-Data: specification of BBC experimental transmissions 1982 (PDF). [S.l.]: Research Department, Engineering Division, The British Broadcasting Corporation. p. 9. Consultado em 11 de outubro de 2013 
  32. Cyclic Redundancy Check (CRC): PSoC Creator™ Component Datasheet. [S.l.]: Cypress Semiconductor. 20 de fevereiro de 2013. p. 4. Consultado em 26 de janeiro de 2016 
  33. «Cyclic redundancy check (CRC) in CAN frames». CAN in Automation. Consultado em 26 de janeiro de 2016 
  34. A signalling standard for trunked private land mobile radio systems (MPT 1327) (PDF) 3rd ed. [S.l.]: Ofcom. Junho de 1997. p. 3-3. Consultado em 16 de julho de 2012 
  35. Rehmann, Albert; Mestre, José D. (fevereiro de 1995). «Air Ground Data Link VHF Airline Communications and Reporting System (ACARS) Preliminary Test Report» (PDF). Federal Aviation Authority Technical Center: 5. Consultado em 7 de julho de 2012 
  36. ETSI EN 300 175-3 (PDF). Col: V2.5.1. Sophia Antipolis, France: European Telecommunications Standards Institute. Agosto de 2013. pp. 99,101. Consultado em 26 de janeiro de 2016 
  37. Thaler, Pat (28 de agosto de 2003). «16-bit CRC polynomial selection» (PDF). INCITS T10. Consultado em 11 de agosto de 2009 
  38. PROFIBUS Specification Normative Parts (PDF). Col: 1.0. 9. [S.l.]: Profibus International. Março de 1998. p. 906. Consultado em 9 de julho de 2016 
  39. a b CAN with Flexible Data-Rate Specification (PDF). Col: 1.0. [S.l.]: Robert Bosch GmbH. 17 de abril de 2012. p. 13. Arquivado do original (PDF) em 22 de agosto de 2013  (3.2.1 DATA FRAME)
  40. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cksum.html
  41. Boutell, Thomas; Randers-Pehrson, Glenn; et al. (14 de julho de 1998). «PNG (Portable Network Graphics) Specification, Version 1.2». Libpng.org. Consultado em 3 de fevereiro de 2011 
  42. a b c d Koopman, Philip (julho de 2002). «32-Bit Cyclic Redundancy Codes for Internet Applications» (PDF). The International Conference on Dependable Systems and Networks: 459–468. ISBN 0-7695-1597-5. doi:10.1109/DSN.2002.1028931. Consultado em 14 de janeiro de 2011 
  43. AIXM Primer (PDF). Col: 4.5. [S.l.]: European Organisation for the Safety of Air Navigation. 20 de março de 2006. Consultado em 4 de julho de 2012 
  44. Gammel, Berndt M. (31 de outubro de 2005). Matpack documentation: Crypto - Codes. [S.l.]: Matpack.de. Consultado em 21 de abril de 2013  (Note: MpCRC.html is included with the Matpack compressed software source code, under /html/LibDoc/Crypto)
  45. Geremia, Patrick (abril de 1999). «Cyclic redundancy check computation: an implementation using the TMS320C54x» (PDF). Texas Instruments (SPRA530): 5. Consultado em 4 de julho de 2012 
  46. Jones, David T. «An Improved 64-bit Cyclic Redundancy Check for Protein Sequences» (PDF). University College London. Consultado em 15 de dezembro de 2009 

Ligações externas[editar | editar código-fonte]

*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


Ver também[editar | editar código-fonte]