Um hash ou soma de verificação criptográfica idêntica para dois arquivos significa que eles são idênticos?

57

Eu tenho 2 documentos do Excel e quero verificar se eles são exatamente iguais, além do nome do arquivo.

Por exemplo, os arquivos são chamados fileone.xlse filetwo.xls. Além dos nomes dos arquivos, presume-se que seu conteúdo seja idêntico, mas é isso que quero verificar.

Eu tenho procurado maneiras de revisar isso e sem instalar um monte de plugins. Não parece um caminho direto.

Eu tentei gerar hashes MD5 para os dois arquivos. Quando os hashes são idênticos, isso significa que o conteúdo do arquivo é 1: 1 o mesmo?

sam
fonte
8
cryptohashes e às vezes até hashes normais podem ser úteis para comparar arquivos em sistemas diferentes ou pesquisar entre um grande número de arquivos, mas se dois arquivos estiverem no mesmo sistema, você poderá facilmente compará-los com o cmpUnix ou fc(comparação de arquivos) no Windows.
Dave_thompson_085
10
shattered.io - SHA1 é um algoritmo de hash "mais forte" que o md5 e ainda shattered.io/static/shattered-1.pdf e shattered.io/static/shattered-2.pdf têm o mesmo valor de hash, sendo completamente diferentes.
isopor voa
30
Nota lateral: verifique primeiro os tamanhos. Se eles têm tamanhos diferentes, não se preocupe em abrir os arquivos, eles são diferentes.
Emilio M Bumachar
42
Versão simplista: um hash MD5 é bom o suficiente para proteger contra um acidente , não é bom o suficiente para evitar novas intenções maliciosas . Se isso é bom o suficiente para você, você deve decidir com base em suas circunstâncias.
Euro Micelli
9
diff -s file1 file2se diz que são idênticos, são idênticos (na verdade, compara os arquivos byte por byte, de modo que até as colisões de hash são excluídas). as somas de verificação são usadas quando você possui apenas um hash e um item que é considerado idêntico ao originador desse hash.
Bakuriu

Respostas:

92

Quando os hashes são idênticos, isso significa que o conteúdo do arquivo é 1: 1 o mesmo?

Todos os arquivos são uma coleção de bytes (valores 0-255). Se dois hashes de MD5 de arquivos corresponderem, ambas as coleções de bytes provavelmente serão exatamente as mesmas (mesma ordem, mesmos valores).

Há uma chance muito pequena de que dois arquivos possam gerar o mesmo MD5, que é um hash de 128 bits. A probabilidade é:

A probabilidade de colisão acidental de apenas dois hashes é 1/2 128, que é 1 em 340 undecilhões 282 decilhões 366 nonilhões 920 octillion 938 septillion 463 sextillion 463 quintilhões 373 quadrilhões 374 quadrilhões 607 trilhões 431 bilhões 768 milhões 211 mil 456. (de uma resposta no StackOverflow .)

Os hashes devem funcionar em "apenas uma direção" - ou seja, você pega uma coleção de bytes e obtém um hash, mas não pode pegar um hash e recuperar uma coleção de bytes.

A criptografia depende disso (é uma maneira de comparar duas coisas sem saber o que são.)

Por volta do ano de 2005, foram descobertos métodos para pegar um hash MD5 e criar dados que correspondam a esse hash, criando dois documentos com o mesmo hash MD5 ( ataque de colisão ). Veja o comentário de @ user2357112 abaixo. Isso significa que um invasor pode criar dois executáveis, por exemplo, que possuem o mesmo MD5 e, se você estiver dependendo do MD5 para determinar em qual confiar, será enganado.

Portanto, o MD5 não deve ser usado para criptografia ou segurança. É ruim publicar um MD5 em um site de download para garantir a integridade do download, por exemplo. Dependendo de um hash MD5, você não se gerou para verificar se o conteúdo de arquivos ou dados é o que você deseja evitar.

Se você gerar o seu próprio, saberá que não está sendo malicioso consigo mesmo (espero). Portanto, para seu uso, não há problema, mas se você quiser que outra pessoa possa reproduzi-lo e queira publicar publicamente o hash MD5, um hash melhor deve ser usado.


Observe que é possível que dois arquivos do Excel contenham os mesmos valores nas mesmas linhas e colunas, mas o bytestream do arquivo seja completamente diferente devido a formatação, estilos, configurações etc. diferentes.

Se você deseja comparar os dados no arquivo, exporte-os para CSV com as mesmas linhas e colunas primeiro, para retirar toda a formatação e, em seguida, faça hash ou compare os CSVs.

LawrenceC
fonte
107
Os arquivos do Excel e outros documentos do escritório também podem ter hashes diferentes porque foram abertos e salvos novamente sem alterar nada, devido aos metadados no arquivo terem um novo valor armazenado nele pela última data e hora salva.
precisa saber é o seguinte
29
Bônus: se você exportou para CSV, pode usar o diffutilitário venerável ou semelhante para confirmar se os arquivos são idênticos em bytes por bytes, em vez de apenas ter o mesmo hash.
Monty Harder
18
Tomar um hash e criar dados que correspondam ao hash é um ataque de pré-imagem. Acredito que o MD5 esteja atualmente vulnerável a ataques de colisão, mas não acho que ataques de pré-imagem ou de segunda pré-imagem sejam viáveis.
User2357112
2
@ Tim o que você está dizendo? Ele disse: exporte-os para CSV e use diff -spara verificar se os CSV são idênticos. Na verdade, você pode diff -saté mesmo os arquivos do Excel: se diffeles forem idênticos, não será necessário compará-los com CSV.
Bakuriu
2
@Bakuriu Claramente, meu comentário foi muito ruim - eu quis dizer que exportar para CSV perderá muita informação - principalmente fórmulas, gráficos, formatação condicional e padrão.
Tim
37

Na prática, sim, um hash criptográfico idêntico significa que os arquivos são os mesmos, desde que os arquivos não tenham sido criados por um invasor ou outra entidade maliciosa. As chances de colisões aleatórias com qualquer função hash criptográfica bem projetada são tão pequenas que são desprezíveis na prática e na ausência de um atacante ativo.

Em geral, no entanto, não, não podemos dizer que dois arquivos arbitrários com o mesmo hash definitivamente significam que eles são idênticos.

A maneira como uma função hash criptográfica funciona é obter uma entrada de comprimento arbitrário e gerar um valor de comprimento fixo calculado a partir da entrada. Algumas funções de hash têm vários comprimentos de saída para escolher, mas a saída ainda é, até certo ponto, um valor de comprimento fixo. Esse valor terá até algumas dezenas de bytes; os algoritmos de hash com o maior valor de saída em uso comum hoje têm uma saída de 512 bits e uma saída de 512 bits é de 64 bytes.

Se uma entrada para uma função hash for maior que a saída da função hash, alguma fidelidade deve ser removida para que a entrada caiba na saída. Conseqüentemente, deve haver várias entradas de comprimentos maiores que o comprimento da saída, que geram a mesma saída.

Vamos tomar o cavalo de batalha atual, SHA-256, como exemplo. Ele gera um hash de 256 bits ou 32 bytes. Se você tiver dois arquivos com exatamente 32 bytes de comprimento, mas diferentes, eles devem (assumindo que não há falha no algoritmo) hash para valores diferentes, independentemente do conteúdo dos arquivos; em termos matemáticos, o hash é uma função que mapeia um espaço de 2 256 entradas para um espaço de 2 256 saídas, o que deve ser possível sem colisões. No entanto, se você tiver dois arquivos com 33 bytes de comprimento, deve existir alguma combinação de entradas que forneça o mesmo valor de hash de saída de 32 bytes para os dois arquivos, porque agora estamos mapeando um espaço de entrada de 2 264 em um 2 256espaço de saída; aqui, podemos ver prontamente que deve haver, em média, 2 8 entradas para cada saída. Vá além e, com arquivos de 64 bytes, devem existir 2 256 entradas para cada saída!

As funções de hash criptográfico são projetadas de forma que seja computacionalmente difícil compor uma entrada que fornece uma saída específica ou compor duas entradas que fornecem a mesma saída. Isso é conhecido como resistência ao ataque de pré-imagem ou resistência ao ataque de colisão . Não é impossível encontrar essas colisões; apenas pretende ser muito, muito, muito, muito difícil. (Um caso especial de ataque de colisão é um ataque de aniversário .)

Alguns algoritmos são melhores que outros para resistir a invasores. O MD5 é geralmente considerado completamente quebrado nos dias de hoje, mas, pela última vez que olhei, ele ainda exibia uma boa resistência à pré-imagem . O SHA-1 também é efetivamente quebrado; ataques de pré-imagem foram demonstrados, mas exigem condições específicas, embora não haja motivo para acreditar que esse será o caso indefinidamente; como diz o ditado, os ataques sempre melhoram, nunca pioram. Atualmente, o SHA-256/384/512 ainda é considerado seguro para a maioria dos propósitos. No entanto , se você estiver interessado apenas em ver se dois códigos não maliciosos, válidosComo os arquivos são iguais, qualquer um desses itens deve ser suficiente, porque o espaço de entrada já está suficientemente restrito para que você se interesse principalmente por colisões aleatórias. Se você tiver algum motivo para acreditar que os arquivos foram criados com intuito malicioso, use pelo menos uma função de hash criptográfico que atualmente é considerada segura, o que coloca a barra inferior no SHA-256.

A primeira pré-imagem é encontrar uma entrada que produza um valor de hash de saída específico; a segunda pré-imagem é encontrar uma entrada que produza a mesma saída que outra entrada especificada; colisão é encontrar duas entradas que produzem a mesma saída, sem levar em consideração o que é isso e, às vezes, sem levar em conta o que são as entradas.

Tudo isso dito, é importante ter em mente que os arquivos podem ter representações de dados muito diferentes e ainda exibir exatamente o mesmo. Portanto, eles podem parecer iguais, mesmo que seus hashes criptográficos não correspondam, mas se os hashes corresponderem, é extremamente provável que pareçam iguais.

um CVn
fonte
2
Se os hashes corresponderem, os arquivos serão o resultado de uma colisão deliberada ou não, e eles serão garantidos . A probabilidade de uma colisão acidental é puramente teórica. Dizer que "se os hashes combinam, é provável que pareçam iguais" é enganoso: se houver malícia em andamento e for uma situação de colisão, eles provavelmente não serão os mesmos e, caso contrário, a probabilidade será efetivamente zero, não é algum evento de baixa probabilidade que precise ser defendido.
Gilles 'SO- stop be evil'
9
@ Gilles: Pelo contrário. As palavras de Michael estão exatamente corretas, e "garantido" é enganoso (ou, bem, factualmente errado). A probabilidade de dois arquivos com hashes idênticos não coincidirem (apesar da modificação maliciosa) é extremamente baixa e pode ser negligenciada na prática. No entanto, não é zero . Geralmente há uma chance, que por qualquer razão diferentes entradas irá produzir o mesmo hash, e possivelmente até mesmo com uma probabilidade muito maior do que 2 ^ -128 (algoritmos de criptografia são arte negra, o algortihm pode ser falho de uma maneira sutil, desconhecido e não temos como ter 100% de certeza).
Damon
5
@Gilles " efetivamente zero " ainda não é zero , o que significa que ainda há alguma probabilidade (reconhecidamente pequena) de que dois conjuntos de dados diferentes resultarão no mesmo hash. Você não pode argumentar contra isso.
Attie
5
@ Attie: A probabilidade de dois arquivos não relacionados serem hashizados com o mesmo valor é tão abaixo da probabilidade de muitas outras coisas que podem dar errado (por exemplo, erros aleatórios de bits corrompendo arquivos no disco) que não vale a pena se proteger contra correspondências coincidentes. A proteção contra partidas deliberadamente projetadas pode valer a pena, mas as partidas acidentais são tão improváveis ​​que qualquer esforço despendido na proteção contra elas provavelmente poderia ser melhor gasto em outro lugar.
Supercat
3
@ Gilles errado. Você não pode me dizer que há uma chance, por menor que seja a sua avaliação, de que uma colisão acidental possa ocorrer e, no próximo beneficiário, nenhuma colisão pode ocorrer. Dizer isso é altamente enganador, pois implica uma propriedade do algoritmo de hash que já é conhecido por ser completamente falso.
Iheanyi # 22/18
10

É um jogo de probabilidade ... os hashes são capazes de representar um número finito de valores.

Se considerarmos um algoritmo de hash de 8 bits hipotético (e muito fraco), isso pode representar 256 valores distintos. Ao começar a executar arquivos pelo algoritmo, você começará a remover hashes ... mas em pouco tempo começará a ver " colisões de hash ". Isso significa que dois arquivos diferentes foram alimentados no algoritmo e produziram o mesmo valor de hash que sua saída. Claramente aqui, o hash não é forte o suficiente e não podemos afirmar que " arquivos com hashes correspondentes têm o mesmo conteúdo ".

Estender o tamanho do hash e usar algoritmos de hash criptográfico mais fortes podem ajudar significativamente a reduzir colisões e aumentar nossa confiança de que dois arquivos com o mesmo hash têm o mesmo conteúdo.

Dito isto, nunca podemos alcançar 100% de certeza - nunca podemos afirmar com certeza que dois arquivos com o mesmo hash realmente têm o mesmo conteúdo.

Na maioria das situações, isso é bom, e comparar hashes é " bom o suficiente ", mas isso depende do seu modelo de ameaça.

Por fim, se você precisar aumentar os níveis de certeza, recomendo que você faça o seguinte:

  1. Use algoritmos de hash fortes (o MD5 não será mais considerado adequado se você precisar se proteger contra usuários potencialmente maliciosos)
  2. Use vários algoritmos de hash
  3. Compare o tamanho dos arquivos - um ponto de dados extra pode ajudar a identificar possíveis colisões, mas observe que a colisão MD5 demonstrada não precisou alterar o comprimento dos dados.

Se você precisa ter 100% de certeza, comece com um hash, mas se os hashes corresponderem, siga-o com uma comparação de byte a byte dos dois arquivos.


Além disso, como apontado por outros ... a complexidade dos documentos produzidos por aplicativos como Word e Excel significa que o texto, os números e o layout visível podem ser os mesmos, mas os dados armazenados no arquivo podem ser diferentes.

O Excel é particularmente ruim nisso - basta abrir uma planilha e salvá-la (sem fazer nada ) pode produzir um novo arquivo, com conteúdo diferente.

Attie
fonte
6
MD5 não é mais considerada adequada é muito verdadeiro cryptographically mas para a verificação de exclusividade (na ausência de malícia, por exemplo, se você controlar a entrada) é bom e rápido (e 128 bits deve ser suficiente)
Chris H
4
" siga-o com uma comparação de byte a byte dos dois arquivos. " Se você quiser fazer uma comparação de arquivos, faça-o primeiro ... não adianta ler todos os arquivos para calcular seus hashes apenas para reler os dois arquivos para compará-los!
TripeHound
3
@TripeHound Depende se os arquivos são locais ou não ... se você já possui um hash de um e está introduzindo um novo arquivo no sistema, se o novo arquivo precisa de um hash armazenado em um banco de dados, etc ... Faça a ligação que melhor se adequa à sua situação.
Attie
5
Não, não é um jogo de probabilidade. Você está subestimando o quão improvável é uma colisão acidental. Isso simplesmente não vai acontecer. Virar um pouco durante a comparação é mais provável. Por outro lado, em alguns cenários, uma colisão deliberada pode acontecer, e esse não é um jogo de probabilidade.
Gilles 'SO- stop be evil'
3
@mbrig: um hash de 32 bits teria um risco significativo de incompatibilidade acidental. Ir para 128 ou 256 bits, no entanto, faz uma enorme diferença. Com 128 bits, um bilhão de macacos digitando um bilhão de documentos genuinamente aleatórios de tamanho decente teria cerca de 0,3% de chance de criar dois documentos com o mesmo hash. Com 256 bits, mesmo que bilhões de macacos possam digitar um bilhão de documentos aleatórios de tamanho decente por segundo por um bilhão de anos, a probabilidade de qualquer um desses milhões de documentos não terem valores de hash coincidentes é muito pequena.
Supercat
6

Se dois arquivos tiverem o mesmo hash MD5 e não tiverem sido criados especialmente, serão idênticos. A dificuldade de criar arquivos com o mesmo hash MD5 depende do formato do arquivo; não sei como é fácil com os arquivos do Excel.

Portanto, se você possui seus próprios arquivos e deseja encontrar duplicatas, o MD5 é seguro. Se você escreveu um dos arquivos e o outro é de origem duvidosa, o MD5 ainda é seguro (a única maneira de obter arquivos diferentes com a mesma soma de verificação MD5 é criar os dois arquivos). Se alguém em quem você não confia envia uma proposta de orçamento e, posteriormente, envia outro arquivo que eles afirmam ser o mesmo, então o MD5 pode não ser suficiente.

Para evitar qualquer risco, use SHA-256 ou SHA-512 em vez de MD5. Se dois arquivos tiverem o mesmo hash SHA-256, eles serão idênticos. O mesmo vale para o SHA-512. (Existe uma possibilidade teórica de que eles possam ser diferentes, mas a probabilidade disso acontecer acidentalmente é muito menor do que a probabilidade do seu computador inverter um pouco durante a verificação do que simplesmente não é relevante. Quanto a alguém criar deliberadamente dois arquivos com o mesmo hash, ninguém sabe como fazer isso no SHA-256 ou SHA-512.)

Se dois arquivos do Excel tiverem hashes diferentes, eles serão diferentes, mas não há como saber quanto eles diferem. Eles podem ter dados idênticos, mas com formatação diferente, ou podem apenas diferir nas propriedades, ou podem ter sido salvos por versões diferentes. De fato, se o Excel for parecido com o Word, apenas salvar um arquivo atualizará seus metadados. Se você deseja comparar apenas os dados numéricos e de texto e ignorar a formatação e as propriedades, pode exportar as planilhas para CSV para compará-las.

Se você possui ferramentas Unix / Linux disponíveis, pode cmpcomparar dois arquivos. Para comparar dois arquivos na mesma máquina, as somas de verificação apenas tornam as coisas mais complicadas.

Gilles 'SO- parar de ser mau'
fonte
Se dois arquivos tiverem o mesmo hash MD5 e não tiverem sido criados especialmente, serão idênticos. Isso está incorreto. Há uma infinidade de mensagens possíveis, mas existem apenas 2 ^ 64 possíveis hashes de 64 bits. Ele é chamado de "princípio do buraco de pombo" : "o princípio do buraco de pombo declara que, se os nitens são colocados em mcontêineres n > m, então pelo menos um contêiner deve conter mais de um item". Se você criar mais de 2 ^ 64 mensagens, terá colisões sem nenhuma "criação especial". E você pode com apenas dois.
Andrew Henle
@AndrewHenle, MD5 não tem 64 bits, é 128. Se gerar uma colisão acidental nos leva a escalas de tempo de morte por calor do universo, é "possível" apenas para uma definição extremamente acadêmica (portanto inútil).
Charles Duffy
@CharlesDuffy Você está assumindo que o hash é distribuído aleatoriamente. Não é.
Andrew Henle
Ser efetivamente equivalente à distribuição aleatória faz parte da definição do que constitui um bom hash criptográfico - você tem várias rodadas de mixagem por um motivo. Certamente, existem algoritmos de hash fracos, mas o foco nessas fraquezas leva-nos às advertências previamente declaradas sobre ataques intencionais. (Ou você está dizendo que o MD5 demonstrou ter apenas 64 bits efetivamente aleatórios? Admito que não tenho acompanhado, então isso é plausível - link por favor?)
Charles Duffy
@AndrewHenle Não afirmo que uma colisão seja matematicamente impossível, o que seria errado, mas não relevante aqui. Afirmo que isso não aconteceu, o que é verdade. Seu comentário está incorreto de uma maneira que altera completamente a oferta. Existem 2 ^ 128 possíveis hashes MD5, não 2 ^ 64. Isso significa que você precisaria gerar 2 ^ 128 hashes para garantir uma colisão. Na verdade, pelo paradoxo do aniversário, 2 ^ 64 daria a você uma chance macroscópica de colisão entre os hashes que você gerou (não com um hash gerado anteriormente). Mas isso é discutível, já que sabemos como criar colisões.
Gilles 'SO- stop be evil'
6

Resposta curta: Um hash criptográfico deve ajudá-lo a ter razoavelmente confiança de que os arquivos com hashes correspondentes são os mesmos. A menos que deliberadamente criado, as chances de dois arquivos ligeiramente diferentes terem valores de hash semelhantes são ridiculamente pequenas. Mas quando se trata de comparar e verificar arquivos que poderiam ser deliberadamente adulterados, o MD5 é uma má escolha. (Use outra função de hash como SHA3 ou BLAKE2.)

Resposta longa: Uma função de hash ideal é aquela que cria um hash criptográfico quase único para todos os dados. Em outras palavras, nós definitivamente sabemos que existem dois arquivos neste universo cujos valores de hash colidem, a chance desses dois arquivos se unirem naturalmente é ridiculamente pequena.

Dez anos atrás, decidi que devia ficar o mais longe possível do MD5. (É claro que até ontem me lembrei do motivo errado; dez anos é muito tempo, você vê. Revi meus memorandos anteriores para lembrar o motivo e editei essa resposta.) Veja, em 1996, o MD5 foi encontrado para ser suscetível a ataques de colisão. 9 anos depois, os pesquisadores conseguiram criar pares de documentos PostScript e (ai!) Certificados X.509 com o mesmo hash! O MD5 estava claramente quebrado. (O Megaupload.com também estava usando o MD5, e houve muita polêmica em torno de colisões de hash que me deram problemas na época.)

Portanto, concluí que, embora o MD5 fosse (e ainda seja) confiável para comparar arquivos benignos, é preciso parar de usá-lo completamente. Eu concluí que confiar nele tem o risco de se transformar em indulgência e falsa confiança: quando você começa a comparar arquivos usando seus hashes MD5, um dia você esquece a impressão fina de segurança e compara dois arquivos deliberadamente criados para ter o mesmo hash. Além disso, é improvável que CPUs e criptoprocessadores adicionem suporte a ele.

O pôster original, no entanto, tem ainda menos motivos para usar o MD5, porque:

  1. Desde que se compare apenas dois arquivos, a comparação de bytes por bytes é realmente mais rápida do que gerar os próprios hashes MD5. Para comparar três ou mais arquivos ... bem, agora você tem uma causa legítima.
  2. O OP especificou "maneiras de revisar isso e sem instalar vários plugins". O comando Get-FileHash do Windows PowerShell pode gerar hashes SHA1, SHA256, SHA384, SHA512 e MD5. Em computadores modernos com suporte de hardware para funções de hash SHA, gerá-las é mais rápido.

fonte
6
Você pode criar sua própria função de hash criptográfico de qualquer tamanho que desejar, true; mas então ele tem um comprimento fixo e o princípio do buraco de pombo se aplica de qualquer maneira. A resposta geral é: "comparando apenas os hashes, você não pode ter certeza de que os dois arquivos são idênticos".
Kamil Maciorowski
2
@KamilMaciorowski Em teoria, sim, eu posso. Minha função hash personalizada pode simplesmente gerar uma cópia do maior arquivo. Mas não tenho interesse em discutir isso mais; a verdade é que você recusou por uma razão que equivale a apontar apenas para provar que é mais inteligente e que o tiro sai pela culatra. Agora você não pode retirar o voto.
Concordo com @KamilMaciorowski ... É um jogo de probabilidade ... usando um único hash, você pode estar " razoavelmente confiante " de que os arquivos com hashes correspondentes são os mesmos, mas não há 100% de garantia. Usar algoritmos melhores ou usar vários algoritmos pode melhorar sua confiança - até mesmo comparar tamanhos de arquivo pode ajudar ... mas você nunca pode estar 100% confiante sem verificar byte a byte.
Attie
11
@Attie Huh! Isso é o que eu quis dizer originalmente. Obrigado. 🙏 Só não estou familiarizado com frases chiques como "você pode estar razoavelmente confiante". Desculpa. Ainda assim, é por isso que temos um botão de edição. Eu, pessoalmente, nunca descartaria uma boa resposta apenas porque uma palavra está errada. Eu edito isso.
11
Sobre "descartar uma boa resposta": lembre-se de garantir que primeiro não seja um erro de digitação e você realmente está falando sério; então diminuiu o voto e, ao mesmo tempo, dei feedback, divulguei minha razão, na esperança de que sua resposta melhore. Sim, então meu voto negativo não existe mais. Basicamente, eu lhe disse o que acho errado com sua resposta, Attie ajudou a esclarecer, você melhorou a resposta. Do meu ponto de vista, todos lidamos com essa situação adequadamente e a história toda acabou muito bem. Obrigado.
Kamil Maciorowski
5

Eu tenho 2 documentos do Excel e quero verificar se eles são exatamente iguais, além do nome do arquivo.

De uma perspectiva prática, comparar diretamente os arquivos para descobrir se eles são diferentes será mais rápido do que computar um hash para cada arquivo e compará-lo.

Para calcular os hashes, você precisa ler todo o conteúdo dos dois arquivos.

Para determinar se eles são idênticos por meio de uma comparação direta, basta ler o conteúdo dos dois arquivos até que eles não correspondam. Depois de encontrar a diferença, você sabe que os arquivos não são idênticos e não precisa ler mais dados de nenhum arquivo.

E antes de fazer qualquer um, você pode simplesmente comparar os tamanhos dos dois arquivos. se os tamanhos diferirem, o conteúdo não poderá ser o mesmo.

Andrew Henle
fonte
Ao usar dois arquivos em uma unidade física, o uso de uma função hash que possa acompanhar a velocidade de E / S em cada arquivo separadamente pode ser um pouco mais rápido do que comparar os arquivos, pois não há necessidade de alternar entre a leitura dos dois arquivos. Os hashes do local realmente brilham, porém, ao tentar fazer comparações envolvendo muitos arquivos grandes demais para caber na memória. Mesmo que você queira apenas descobrir se todos eles correspondem, comparando o arquivo 1 ao arquivo 2, o arquivo 1 ao arquivo 3 e o arquivo 1 ao arquivo 4 etc. podem ser quase duas vezes mais lentos do que calcular todos os hashes.
Supercat
@supercat Se os arquivos forem lidos em pedaços maiores que um MB ou mais, a alternância entre arquivos não será perceptível. E se um fluxo de trabalho envolve a comparação de vários arquivos para encontrar duplicatas, o hash pode ser calculado à medida que cada arquivo é gravado - já que isso pode ser feito gratuitamente.
Andrew Henle
Se houver espaço suficiente para armazenar grandes quantidades de arquivos em buffer, os tempos de alternância não precisarão ser um problema, mas podem ser. Quanto ao cálculo dos hashes quando os arquivos são gravados, isso pode ser bom se for possível garantir que os arquivos não possam ser modificados sem alterar ou pelo menos invalidar os hashes armazenados. Se alguém estiver tentando evitar fazer backup de arquivos de forma redundante, olhar apenas para os valores de hash armazenados pode fazer com que você faça backup de um arquivo corrompido acidentalmente, mas não se preocupe em fazer backup dos arquivos não corrompidos aos quais o arquivo corrompido deve corresponder, mas não .
Supercat
"Depois de encontrar a diferença, você sabe que os arquivos não são idênticos" - não necessariamente. Arquivos XLSX são arquivos ZIP que potencialmente podem armazenar o conteúdo em ordem diferente, ainda tendo o mesmo conteúdo. Mas mesmo se você descompactá-los e comparar cada arquivo individual, o arquivo XLSX contém documentos XML que podem ter, por exemplo, diferentes terminações de linha sem afetar o conteúdo.
Thomas Weller
5

Hashes como MD5 ou SHA têm tamanho fixo, digamos que são 300 caracteres alfanuméricos (na realidade, são mais curtos e não usam todo o conjunto de caracteres alfanuméricos).

Digamos que os arquivos sejam feitos de caracteres alfanuméricos e com tamanho de até 2 GB.

Você pode ver facilmente que há muito mais arquivos (com tamanho de até 2 GB) do que possíveis valores de hash. O princípio pigeonhole diz que alguns arquivos (diferentes) devem ter os mesmos valores de hash.

Além disso, como demonstrado no shattered.io 1, é possível ter dois arquivos diferentes: shattered.io/static/shattered-1.pdf e shattered.io/static/shattered-2.pdf que possuem o mesmo valor de hash SHA-1 enquanto estão completamente diferente.

1 SHA1 é um algoritmo de hash "mais forte" que o md5

mosca de isopor
fonte
A probabilidade de colisões acidentais é muito baixa para ser levada em consideração. O risco de uma colisão deliberada também existe para o MD5 e é pior do que para o SHA-1, que não é muito relevante aqui.
Gilles 'SO- stop be evil'
4

NÃO. Valores diferentes garantem que os arquivos sejam diferentes. Os mesmos valores não são garantia de que os arquivos são os mesmos. É relativamente fácil encontrar exemplos usando o CRC16.

No balanço de probabilidade dos esquemas de hash contemporâneos, eles são os mesmos.

mckenzm
fonte
11
A questão é sobre o MD5, que não tem risco de colisões acidentais. Existe o risco de colisões deliberadas, mas isso não é uma questão de probabilidades.
Gilles 'SO- stop be evil'
11
Também se trata de planilhas do Excel com nomes diferentes, qual o tamanho que uma comparação de bytes para comparação de bytes não pode ser uma opção? Dois esquemas de hash juntos forneceriam segurança.
Mckenzm
2
@Gilles Todos os códigos de hash têm risco de colisões acidentais, por definição. A única maneira de sair disso é usar o arquivo inteiro como o código de hash. Seu comentário não faz sentido.
User207421
3

Porém, sua pergunta é inversa - vamos supor que o hash significa que eles têm os mesmos dados (o que não é 100% garantido, mas é bom o suficiente para uma vida inteira comparando arquivos a cada segundo para não causar uma colisão). Isso não significa necessariamente que ter os mesmos dados significa que eles terão o mesmo hash. Portanto, não - você não pode comparar os dados em um arquivo do Excel com os dados de outro arquivo do Excel, fazendo o hash do arquivo, porque existem muitas maneiras pelas quais dois arquivos podem diferir sem que os dados subjacentes sejam diferentes. Uma maneira óbvia - os dados são armazenados como XML, cada célula possui seu próprio nó XML. Se esses nós forem armazenados em ordens diferentes, os dados serão os mesmos, mas o arquivo será diferente.

David Rice
fonte
3

Para adicionar outras respostas, aqui estão muitos exemplos de pares de arquivos com o mesmo hash MD5 e conteúdo diferente.

Giulio Muscarello
fonte
Uma resposta apenas para links, mas interessante.
Thomas Weller
2

A resposta para este OP foi dada, mas pode se beneficiar de um resumo.

Se você deseja verificar se dois arquivos são iguais, muito depende se os arquivos e hashes estão sob seu controle.

Se você mesmo gerar os hashes a partir dos arquivos e tiver certeza de que ninguém mais teve oportunidade / habilidade / motivação para tentar deliberadamente chegar à conclusão errada, quase todos os hash - mesmo os hashes "quebrados" conhecidos, como MD5 e SHA1, serão quase certo de ser suficiente. Mas isso significa que você pode gerar arquivos em alta velocidade por milhões de anos e ainda é improvável que acabe com dois arquivos realmente diferentes, mas com o mesmo hash. É quase certamente seguro.

Este é o cenário que você tem, quando deseja verificar rapidamente se dois diretórios no seu PC ou servidor de arquivos têm o mesmo conteúdo, se algum arquivo em um diretório é duplicado exato, etc., e você tem certeza de que os arquivos não foram foi projetado / modificado ilicitamente e você confia no seu aplicativo / utilitário de hash para fornecer os resultados corretos.

Se você estiver em um cenário em que um dos arquivos - ou um hash pré-calculado - possa ter sido manipulado ou projetado para levar você a uma conclusão errada, será necessário um hash mais forte (ininterrupto) e / ou outra segurança. Por exemplo, se você baixar um arquivo e verificar se ele é válido examinando um hash, um invasor poderá projetar um arquivo incorreto com o hash correto ou atacar o site para colocar um hash incorreto ao procurar a opção "correta". " (valor esperado. Isso se resume a problemas de segurança mais amplos.

Stilez
fonte
2

Na linha de comando do Windows, você pode usar o computilitário para determinar se dois arquivos são exatamente iguais. Por exemplo:

comp fileone.xls filetwo.xls
Chade
fonte
1

Quando os hashes são idênticos, isso significa que o conteúdo do arquivo é 1: 1 o mesmo?

Não. Se os hashes são diferentes, isso não significa que os conteúdos são diferentes. Hashcodes iguais não implicam conteúdo igual. Um código de hash é uma redução de um domínio grande para um intervalo menor, por definição: a implicação é que códigos de hash sobre conteúdo desigual podem ser iguais. Caso contrário, não faria sentido computá-los.

user207421
fonte
Caso contrário, não faria sentido computá-los. Se você violou as leis da matemática e inventou uma função de compressão sem perdas que pode comprimir dados aleatórios, violando o princípio do buraco de pombo, seria muito valioso usá-los! Seria muito conveniente se a 128 bits de hash que representam exclusivamente todo o conteúdo de um arquivo. Mesmo se não houvesse uma função de descompactação para transformar o hash novamente no arquivo, seria bom ter um hash sem colisão matematicamente impossível, por exemplo, para acelerar a localização de dados duplicados em dados não confiáveis, como nas imagens de VM.
Peter Cordes
"Se os hashes são diferentes, isso significa que o conteúdo é diferente." Não necessariamente. Arquivos XLSX são arquivos ZIP e seria possível ter o mesmo conteúdo armazenado em ordem de arquivo diferente.
Thomas Weller
1

Esta resposta pretende ser um mapa útil de cenários que podem ou não acontecer, e raciocínios que você pode aplicar. Consulte outras respostas para saber por que as funções hash funcionam dessa maneira.


Depois de escolher uma função de hash e cumpri-la, estas são todas as combinações a serem consideradas:

          |    identical   |   different    |
          |   hash values  |  hash values   |
----------+----------------+----------------+
identical |   can happen,  | cannot happen, |
  files   |     common     |   impossible   |
----------+----------------+----------------+
different |   can happen,  |   can happen,  |
  files   |      rare*     |     common     |
----------+----------------+----------------+

* rare, unless whoever generates (at least one of) the files
  purposely aims at this scenario

O cenário em que arquivos idênticos geram valores diferentes de hash é o único estritamente impossível.


Dois raciocínios que sempre se aplicam:

  • Se os arquivos forem idênticos, os valores de hash serão idênticos, com certeza .
  • Se os valores de hash forem diferentes, os arquivos serão diferentes, com certeza .

Dois raciocínios que não são estritos :

  • Se os arquivos forem diferentes, os valores de hash provavelmente serão diferentes.
  • Se os valores de hash forem idênticos, os arquivos provavelmente serão idênticos.
Kamil Maciorowski
fonte
0

Para seus propósitos, sim, hashes idênticos significam arquivos idênticos.

Como outras respostas deixam claro, é possível construir 2 arquivos diferentes que resultam no mesmo hash e o MD5 não é particularmente robusto nesse sentido.

Portanto, use um algoritmo de hash mais forte se você planeja comparar um grande número de documentos do Excel ou se acha que alguém pode querer manipular a comparação. SHA1 é melhor que MD5. O SHA256 é melhor novamente e deve fornecer total confiança para seu uso específico.

jah
fonte
-1

Os arquivos provavelmente são idênticos se seus hashes forem idênticos. Você pode aumentar a confiança modificando os dois arquivos de maneira idêntica (por exemplo, coloque o mesmo valor na mesma célula não utilizada) e comparando os hashes dos arquivos modificados. É difícil criar uma colisão deliberada para um arquivo que é alterado de uma maneira que não se conhece previamente.

ibft2
fonte
Isso não funcionará devido a dados adicionais armazenados em arquivos do escritório. Você precisa, por exemplo, colocar o cursor na mesma célula antes de salvar, salvar no horário exato etc. Mas, mesmo assim, os arquivos XLSX são arquivos zip internamente; portanto, se esse algoritmo armazenar os arquivos individuais em uma ordem diferente (para qualquer finalidade), o arquivo é idêntico, mas o hash não é #
Thomas Weller
-2

Vejamos isso de uma maneira prática. Em vez de dizer "os hashes são idênticos", direi "escrevi um programa de computador que calcula os hashes de dois arquivos e imprime se são iguais ou não", e executo o programa com dois arquivos, e diz "idêntico". Existem várias razões pelas quais isso pode ser feito:

Os arquivos podem ser idênticos. Meu código pode ter erros (um que realmente aconteceu na prática foi comparar dois hashes longos (256 bytes), não com o memcmp, mas com o strcmp: A comparação retornará "mesmo" se o primeiro byte em cada hash for zero e a chance de ou seja, 1 em 65536. Pode haver uma falha de hardware (raio cósmico atingindo uma célula de memória e alternando-a) ou você pode ter o caso raro de dois arquivos diferentes com hash idêntico (uma colisão de hash).

Eu diria que, para arquivos não idênticos, de longe a causa mais provável é erro do programador, então vem o raio cósmico que mudou uma variável booleana com o resultado da comparação dos hashes de "falso" para "verdadeiro" e muito mais tarde a coincidência de uma colisão de hash.

Existem sistemas de backup corporativo que evitam fazer backup de arquivos idênticos de 10.000 usuários, fazendo hash em cada arquivo e verificando se há um arquivo com um hash idêntico já armazenado no servidor. Portanto, em caso de colisão, um arquivo não será copiado, possivelmente causando perda de dados. Alguém calculou que é muito mais provável que um meteorito atinja seu servidor e destrua todos os backups do que a perda de um arquivo porque sua soma de verificação corresponde a um arquivo diferente.

gnasher729
fonte