O CRC funciona bem para detectar erros aleatórios nos dados que podem ocorrer, por exemplo, por interferência na rede, ruído na linha, distorção etc.
O CRC é computacionalmente muito menos complexo que o MD5 ou o SHA1. Usar uma função de hash como MD5 provavelmente é um exagero para a detecção de erros aleatórios. No entanto, o uso do CRC para qualquer tipo de verificação de segurança seria muito menos seguro do que uma função de hash mais complexa, como o MD5.
E sim, o CRC é muito mais fácil de implementar em hardware incorporado; você pode até obter soluções em pacotes diferentes para isso no IC.
@ gili: você sempre pode simplesmente xor as dwords juntas para obter uma única dword resultante.
@Dustin: Você está completamente correto em sua resposta, mas talvez considere alterar "o CRC é computacionalmente muito mais eficiente" para "CRC é computacionalmente muito mais fácil"? Os algoritmos MD5 / SHA-1 são complexos, mas não são realmente IMO 'ineficientes'.
@ coxymla você está correto, a palavra que eu deveria ter usado é "complexo" e não "ineficiente". Obrigado!
Para reduzir qualquer hash longo para 32 bits, basta pegar os primeiros 32 bits.
— orip 24/05
Se a segurança é seu objetivo, você nunca deve usá-lo MD5, SHA-1também deve ser evitado, SHA-2é recomendável alguma variante .
O CRC é projetado contra alterações não intencionais nos dados. Ou seja, é bom para detectar erros não intencionais, mas será inútil como forma de garantir que os dados não sejam tratados com códigos maliciosos.
A parte mais importante do link nesta resposta: "(...) até um CRC de 2048 bits seria criptograficamente muito menos seguro que um MD5 de 128 bits"
Enquanto a resposta ainda estiver correta, o MD5 e o SHA1 estão no mesmo nível de segurança atualmente. Em outras palavras, apenas é bom para detectar erros não intencionais.
Eu encontrei um estudo que mostra o quão inadequados os hashes CRC são para tabelas de hash . Também explica as características reais do algoritmo. O estudo também inclui a avaliação de outros algoritmos de hash e é uma boa referência a ser mantida.
A conclusão relevante sobre CRC para hashes:
O CRC32 nunca foi destinado ao uso da tabela de hash. Não há realmente nenhuma boa razão para usá-lo para esse fim, e eu recomendo que você evite fazê-lo. Se você decidir usar o CRC32, é fundamental que você use os bits de hash do final oposto àquele em que os octetos-chave são alimentados. Qual final depende da implementação específica do CRC32. Não trate o CRC32 como uma função de hash "caixa preta" e não o use como um hash de uso geral. Certifique-se de testar cada aplicativo para verificar a adequação.
Parece que o site está fora do ar. O arquivo da Internet possui uma cópia .
Link quebrado. Talvez você possa escrever a explicação você mesmo? Caso contrário, a resposta é inútil.
Ok, vou incluir a conclusão na minha resposta.
Estranho, de acordo com a referência aqui , o CRC realmente se sai muito bem em termos de velocidade e número de colisões.
— Ostrokach # 15/15
Muito interessante mesmo. Eu tive que examinar o estudo ao qual vinculei novamente, mas se eu tiver que adivinhar, deve ser por causa das diferentes implementações de teste. Se eu tivesse que tomar uma decisão, seguiria o conselho do estudo, parece ser cientificamente mais sólido.
— Andre Luus 15/09/2015
Na minha experiência com hash de milhões de URLs, o CRC64 colidiu 8 vezes e o MD5 colidiu com 5. Obviamente, o MD5 foi melhor, mas o CRC64 foi um hash excelente, muito mais rápido e mais simples.
— J. Dimeo 12/06
Eu corri todas as linhas deste código PHP em 1.000.000 de loop. Os resultados estão nos comentários (#).
Use "crc32b" quando precisar http://en.wikipedia.org/wiki/Cyclic_redundancy_check e não se preocupa com segurança.
Use "sha256" (ou superior) quando precisar de uma camada de segurança adicionada.
Não use "md5" ou "sha1" porque eles têm:
alguns problemas de segurança quando você se preocupa com segurança
cadeia de hash mais longa e mais lenta que "crc32b" quando tudo que você precisa é CRC
você quer dizer bits, não caracteres
Na verdade não. echo hash ('crc32', 'A rápida raposa marrom pulou sobre o cachorro preguiçoso.'); ecoa "413a86af", que é uma sequência de 8 caracteres. Aliás, é um número de 32 bits armazenado no formato HEX. Por exemplo, "sha256" possui um hash de 256 bits, novamente armazenado como HEX, o que fornece uma cadeia longa de 64 caracteres.
Estes resultados são muito enganadores. Quando esses algoritmos de hash são aplicados a um grande conjunto de dados ( Guerra e Paz em vez de "The quick brown fox jumped over the lazy dog."), você veria o quão mais rápido o CRC é do que o MD5.
Há um caso intermediário (verificação duplicada nas bibliotecas) em que MD5 / Sha1 é a solução correta: eles não precisam lidar com o caso em que há um adversário criando cuidadosamente a colisão de hash que é improvável, mas precisam lidar com colisões acidentais. Portanto: Detectando erros de bit e corrupção: CRC32 Detectando colisões nas bibliotecas: MD5 / SHA1 Aplicativos adversos: Sha256 e superior. Obviamente, se você possui uma biblioteca com bilhões de entradas, provavelmente também precisará aumentar seus bits de hash.
— Dewi Morgan 24/05
PHP? em uma plataforma ARM, código incorporado, 16MHz a CRC32 de 46 bytes, talvez 12 microssegundos. Que possui assistência de hardware. Até o AES assistido por hardware seria centenas de vezes mais lento. A tabela de pesquisa não assistida ainda deve chegar em cerca de 50 microssegundos.
— Ilgitano 15/08/19
Para obter informações sobre implementação, velocidade e confiabilidade do CRC, consulte Um guia simples para algoritmos de detecção de erros do CRC . Tem tudo sobre CRCs.
A menos que alguém tente modificar seus dados com intuito malicioso e ocultar a mudança, a CRC é suficiente. Basta usar um polinômio "Bom" (padrão).
Tudo depende de suas necessidades e expectativas.
Aqui estão breves diferenças breves entre estes algoritmos de função hash :
não é um algoritmo de hash criptográfico (está usando uma função linear baseada em verificações de redundância cíclica)
pode produzir 9, 17, 33 ou 65 bits
não se destina a ser utilizado para fins criptográficos, uma vez que não oferece garantias criptográficas,
inadequado para uso em assinaturas digitais, porque é facilmente reversível em 2006 ,
não deve ser usado para fins de criptografia,
cadeias diferentes podem gerar a colisão,
inventado em 1961 e usado em Ethernet e em muitos outros padrões,
é um algoritmo de hash criptográfico,
produzindo um valor de hash de 128 bits (16 bytes) (números hexadecimais de 32 dígitos)
é um hash criptográfico, mas é considerado obsoleto se você se preocupar com segurança,
existem cadeias conhecidas que têm o mesmo valor de hash MD5
pode ser usado para fins de criptografia,
produz um valor de hash de 160 bits (20 bytes) conhecido como resumo da mensagem
é um hash criptográfico e, desde 2005, não é mais considerado seguro,
foi encontrado um exemplo de uma colisão sha1
publicado pela primeira vez em 1993 (como SHA-0), depois 1995 como SHA-1,
série: SHA-0, SHA-1, SHA-2, SHA-3,
Em resumo, usando SHA-1 não é mais considerado seguro contra adversários bem financiados, porque em 2005, cryptanalysts encontrados ataques em SHA-1, que sugere que pode não ser suficiente seguro para uso em curso Schneier . O NIST dos EUA recomenda que as agências federais devem parar de usar o SHA1-1 para aplicativos que exijam resistência à colisão e devem usar o SHA-2 após o NIST de 2010 .
Portanto, se você estiver procurando por uma solução simples e rápida para verificar a integridade de um arquivo (contra a corrupção) ou por alguns propósitos simples de armazenamento em cache em termos de desempenho, considere o CRC-32, e, em hash, considere usar MD5, no entanto, se você estiver desenvolvendo um aplicativo profissional (que deve ser seguro e consistente), para evitar qualquer probabilidade de colisão - use o SHA-2 e superior (como o SHA-3).
Alguns testes simples de benchmark em PHP:
Qual é a diferença entre md5 (), crc32 () e sha1 () crypto no PHP?
Você não diz o que está tentando proteger.
Um CRC é frequentemente usado em sistemas incorporados como uma verificação contra corrupção acidental de dados, em vez de impedir modificações maliciosas no sistema. Exemplos dos locais onde um CRC pode ser útil é validar uma imagem EPROM durante a inicialização do sistema para evitar corrupção de firmware. O carregador de inicialização do sistema calculará o CRC para o código do aplicativo e comparará com o valor armazenado antes de permitir a execução do código. Isso protege contra a possibilidade de corrupção acidental do programa ou falha no download.
Um CRC também pode ser usado de maneira semelhante para proteger os dados de configuração armazenados no FLASH ou EEPROM. Se o CRC estiver incorreto, os dados poderão ser sinalizados como inválidos e um conjunto de dados padrão ou de backup usado. O CRC pode ser inválido devido a falha do dispositivo ou se o usuário removeu a energia durante uma atualização do armazenamento de dados de configuração.
Houve comentários de que um hash fornece maior probabilidade de detectar corrupção do que um CRC com erros de vários bits. Isso é verdade, e a decisão de usar ou não um CRC de 16 ou 32 bits dependerá das consequências de segurança de um bloco de dados corrompido sendo usado e se você pode justificar a chance 1 em 2 ^ 16 ou 2 ^ 32 de uma bloco de dados sendo declarado incorretamente válido.
Muitos dispositivos possuem um gerador CRC embutido para algoritmos padrão. A série MSP430F5X do Texas possui uma implementação de hardware do padrão CRC-CCITT.
O CRC32 é mais rápido e o hash tem apenas 32 bits.
Use-o quando quiser apenas uma soma de verificação rápida e leve. O CRC é usado em ethernet.
Se você precisar de mais confiabilidade, é preferível usar uma função de hash moderna.
Use o CRC apenas se os recursos de computação forem muito restritos (por exemplo, alguns ambientes incorporados) ou se você precisar armazenar / transportar muitos valores de saída e o espaço / largura de banda for restrito (como os CRCs geralmente são de 32 bits, onde uma saída MD5 é de 128 bits, SHA1 160 bit e outras variantes SHA de até 512 bits).
Nunca use o CRC para verificações de segurança, pois é muito fácil "falsificar" um CRC.
Mesmo para detecção acidental de erros (em vez de detecção maliciosa de alterações), os hashes são melhores que um simples CRC. Em parte devido à maneira simples como uma CRC é calculada (e em parte porque os valores da CRC geralmente são mais curtos que as saídas de hash comuns e, portanto, têm um intervalo muito menor de valores possíveis), é muito mais provável que, em uma situação em que haja dois ou mais erros , um erro mascarará outro e você terminará com o mesmo CRC, apesar de dois erros.
Em resumo: a menos que você tenha motivos para não usar um algoritmo de hash decente, evite CRCs simples.
O CRC capturará todas as alterações acidentais de dados se você estiver usando um polinômio adequado. 1/2 ^ 32 alterações são perdidas se exatamente os vários bits corretos forem alterados.
E com um polinômio adequado, ele também captura todos os erros de determinadas classes comuns, por exemplo, erros de burst.
Eu concordo com sua resposta, exceto que a pergunta é sobre sistemas embarcados. O desempenho de um algoritmo criptográfico pode ser problemático em sistemas embarcados menores.
— 22716 Craig McQueen
Discordo absolutamente disso. Os polinômios de erro CRC são cuidadosamente escolhidos para que possam detectar 1,2,3,5 e, em alguns casos, detectar erros de até 11 bits. Um hash criptográfico é puramente estatístico, portanto, você deve usar grandes valores de resumo. 8-32 bits não são realistas para um resumo criptográfico de hash, além de desnecessariamente caro em cpu cyles e portões. Definitivamente, não é uma resposta a ser adotada se você trabalha em sistemas embarcados. O único momento para NÃO usar um CRC é se você tiver que lidar com um cenário adversário inteligente.
Me deparei com um uso de CRC recentemente, que era inteligente. O autor do ferramenta de identificação e remoção de duplicação de arquivo jdupe (o mesmo autor do popular jhead da ferramenta exif) o usa durante a primeira passagem pelos arquivos. Um CRC é calculado nos primeiros 32K de cada arquivo para marcar os arquivos que parecem iguais, também os arquivos devem ter o mesmo tamanho. Esses arquivos são adicionados a uma lista de arquivos nos quais é feita uma comparação binária completa. Acelera a verificação de grandes arquivos de mídia.
Um problema com essa abordagem é quando executado em um arquivo que contém um CRC32 incorporado, o CRC resultante pode ser independente dos dados no arquivo (pois, se os dados forem alterados, o CRC32 será alterado para cancelar a diferença. ) Munging os dados de uma maneira simples antes de calcular o CRC32 evitaria esse problema.
@ supercat - Eu realmente não acredito que isso seja realmente um problema. Se um arquivo contiver um cabeçalho crc32, que é o crc32 do restante do arquivo, quando o arquivo for atualizado, cada bit no cabeçalho crc32 terá aproximadamente 50% de chance de ser diferente. As alterações no cabeçalho devem seguir uma distribuição bastante aleatória. Não consigo ver como isso resultará no CRC32 (cabeçalho + dados) sempre sendo o mesmo ou de qualquer forma não dependente da parte de dados do arquivo.
— teratorn 28/05
@teratorn: Eu vi vários arquivos que possuem um CRC32 no final, calculados de tal maneira que o CRC32 de todo o arquivo, calculado usando alguma constante de semente específica, sempre será outro valor constante. Isso é bastante comum em coisas como imagens de código binário. Se o DVD player Acme 1000 usar imagens de código de tamanho fixo para atualizações de firmware e esperar que cada imagem de código tenha um determinado CRC32, uma rotina que calcule os vários arquivos do CRC32 não poderá distinguir imagens de código diferentes para o Acme 1000.
O ponto da CRC nesse caso é identificar rapidamente que os arquivos são diferentes. Se o CRC voltar da mesma forma, você precisará fazer uma comparação binária cara, para que um CRC incorporado não quebre o algoritmo. Pode acontecer que alguns arquivos acabem sendo binários em comparação porque a primeira passagem do CRC diz que PODE ser a mesma, mas é improvável que sejam muitos deles, e você pode evitá-lo usando um polinômio personalizado.
O CRC32 é muito mais rápido e às vezes possui suporte de hardware (ou seja, nos processadores Nehalem). Realmente, a única vez em que você o utilizaria seria se estivesse fazendo uma interface com o hardware ou se estivesse realmente com pouco desempenho.
Na criptografia, um algoritmo de hash converte muitos bits em menos bits por meio de uma operação de digestão. Hashes são usados ​​para confirmar a integridade de mensagens e arquivos.
Todos os algoritmos de hash geram colisões. Uma colisão é quando várias combinações de muitos bits produzem a mesma saída de menos bits. A força criptográfica de um algoritmo de hash é definida pela incapacidade de um indivíduo determinar qual será a saída para uma determinada entrada, porque, se pudessem, poderiam construir um arquivo com um hash que corresponda a um arquivo legítimo e comprometer a integridade assumida. do sistema. A diferença entre o CRC32 e o MD5 é que o MD5 gera um hash maior que é mais difícil de prever.
Quando você deseja implementar a integridade da mensagem - o que significa que a mensagem não foi violada em trânsito - a incapacidade de prever colisões é uma propriedade importante. Um hash de 32 bits pode descrever 4 bilhões de mensagens diferentes ou arquivos diferentes usando 4 bilhões de hashes exclusivos diferentes. Se você tiver 4 bilhões e 1 arquivos, você terá 1 colisão. 1 TB Bitspace tem a possibilidade de bilhões de colisões. Se eu sou um invasor e posso prever o que esse hash de 32 bits será, posso construir um arquivo infectado que colide com o arquivo de destino; que tem o mesmo hash.
Além disso, se estou fazendo uma transmissão de 10mbps, a possibilidade de um pacote ser corrompido da maneira certa para ignorar o crc32 e continuar até o destino e a execução é muito baixa. Vamos dizer que em 10mbps eu recebo 10 erros \ segundo . Se eu aumentar isso até 1gbps, agora estou recebendo 1.000 erros por segundo . Se eu ram até 1 exabit por segundo, tenho uma taxa de erro de 1.000.000.000 de erros por segundo . Digamos que tenhamos uma taxa de colisão de 1 \ 1.000.000erros de transmissão, ou seja, 1 em um milhão de erros de transmissão resulta na obtenção de dados corrompidos sem serem detectados. Com 10mbps, eu recebia dados de erro sendo enviados a cada 100.000 segundos ou aproximadamente uma vez por dia. A 1 gbps, isso acontece uma vez a cada 5 minutos. Com 1 exabit por segundo, estamos conversando várias vezes por segundo.
Se você abrir o Wireshark, verá que seu cabeçalho Ethernet típico possui um CRC32, seu cabeçalho IP possui um CRC32 e seu cabeçalho TCP possui um CRC32, além do que os protocolos de camada superior podem fazer; por exemplo, o IPSEC pode usar MD5 ou SHA para verificação de integridade, além do acima. Existem várias camadas de verificação de erros nas comunicações de rede típicas e elas continuam ocorrendo de vez em quando em velocidades inferiores a 10 Mbps.
A Verificação cíclica de redundância (CRC) tem várias versões comuns e várias incomuns, mas geralmente é projetada apenas para saber quando uma mensagem ou arquivo foi danificado em trânsito (inversão de vários bits). O CRC32 por si só não é um protocolo muito bom de verificação de erros pelos padrões atuais em ambientes corporativos grandes e escalares, devido à taxa de colisão; o disco rígido médio dos usuários pode ter mais de 100 mil arquivos e os compartilhamentos de arquivos em uma empresa podem ter dezenas de milhões. A proporção de espaço de hash e o número de arquivos é muito baixa. O CRC32 é computacionalmente barato de implementar, enquanto o MD5 não.
O MD5 foi projetado para interromper o uso intencional de colisões para fazer com que um arquivo malicioso pareça benigno. É considerado inseguro porque o espaço de hash foi suficientemente mapeado para permitir que alguns ataques ocorram e algumas colisões são previsíveis. SHA1 e SHA2 são as novas crianças do quarteirão.
Para a verificação de arquivos, o Md5 está começando a ser usado por muitos fornecedores, porque você pode criar rapidamente arquivos com vários dígitos ou arquivos com vários bits de memória e empilhá-lo além do uso e suporte de CRC32 do sistema operacional geral. Não se surpreenda se, na próxima década, os sistemas de arquivos começarem a usar o MD5 para verificação de erros.