O MD5 ainda é bom o suficiente para identificar arquivos exclusivamente?


139

O hash MD5 de um arquivo ainda é considerado um método bom o suficiente para identificá-lo exclusivamente, considerando todas as falhas do algoritmo MD5 e problemas de segurança etc? A segurança não é minha principal preocupação aqui, mas é a identificação exclusiva de cada arquivo.

Alguma ideia?


2
Atualmente, estou usando-o em um dos meus aplicativos e, até onde sei, é bom o suficiente para identificar arquivos de forma exclusiva.
Não disponível

2
Você provavelmente encontrará esta pergunta: stackoverflow.com/questions/862346/… útil.
Sharptooth 27/10/10

Quantos arquivos você precisa identificar? Ele gera 128 bits, portanto, se você estiver tentando identificar alguns milhares de arquivos, tudo bem. Mas se você está tentando identificar muito mais do que isso, pode se deparar com colisões / o paradoxo do aniversário.
Marcin

Eles serão arquivos de imagem, jpg, png e gif. E sim, acho que o limite seria de alguns milhares ... Mas quantos arquivos você acha que vai me causar problemas?
Ranhiru Jude Cooray

Respostas:


89

Sim. O MD5 foi completamente quebrado da perspectiva de segurança, mas a probabilidade de uma colisão acidental ainda é muito pequena. Apenas certifique-se de que os arquivos não estejam sendo criados por alguém em quem você não confia e que possa ter intenções maliciosas.


2
@one: Para sua primeira pergunta, veja aqui . Receio não entender as outras perguntas.
Marcelo Cantos

9
@ 0xA3: Nem você nem eu temos alguma idéia de quais arquivos o OP está se referindo ou quanto dano um comprometimento causaria. Pode ser a coleção de fotos de bebês de seus filhos, pelo que sabemos. Meu objetivo é fornecer os fatos; o que outra pessoa faz com eles é problema deles. Considere também que Bruce Schneier recomenda anotar sua senha; nem tudo precisa ser armazenado em Fort Knox. Algumas coisas vão ficar bem embaixo do vaso de flores.
Marcelo Cantos

3
@ Marcelo Cantos, acho que falta aqui uma diferenciação ou descompactação do termo 'segurança'. Obviamente, as pessoas estão assumindo 'segurança' por qualquer uso do trabalho de soma de verificação, mas a nomenclatura que Marcelo provavelmente quer dizer é 'em laboratório'.
Hpavc 27/10/10

5
Eu discordo fortemente. Um valor de hash diferente informa que os arquivos são diferentes. Mas para um valor de hash igual: você não pode dizer "é altamente provável que ambos sejam iguais" se o hash for o mesmo: você só pode comparar byte a byte. Um hash é muitas ordens de magnitude menor que o número de valores diferentes para todo o arquivo; portanto, existem muitas colisões possíveis para cada valor de hash. Somente se você estiver copiando um arquivo conhecido (com um hash conhecido) é que um valor de hash idêntico "provavelmente significa" que o segundo foi copiado corretamente (mesmo assim, não é 100% certo, mas é muito provável).
Olivier Dulac

3
OK, minha matemática é péssima. Os GUIDs têm cerca de 122 bits de entropia e, portanto, a probabilidade de uma colisão em qualquer lugar em um bilhão de arquivos é de cerca de 2 ^ (2 * 30 - 122) = 2 ^ -62. Embora isso seja muito superior ao meu cálculo original, ainda é minúsculo em aproximadamente um em cada quatro quintilhões.
Marcelo Cantos

32

Para fins práticos, o hash criado pode ser adequadamente aleatório, mas teoricamente sempre há uma probabilidade de colisão, devido ao princípio Pigeonhole . Ter hashes diferentes certamente significa que os arquivos são diferentes, mas obter o mesmo hash não significa necessariamente que os arquivos sejam idênticos.

O uso de uma função de hash para esse fim - não importa se a segurança é uma preocupação ou não - deve, portanto, sempre ser apenas o primeiro passo de uma verificação, especialmente se o algoritmo de hash for conhecido por criar colisões com facilidade. Para descobrir com segurança se dois arquivos com o mesmo hash são diferentes, você precisará comparar esses arquivos byte a byte.


16
@Ranhiru. Não. O hash fornece um valor de 'resumo' que (para MD5) tem apenas 16 bytes. Para garantir que os arquivos sejam idênticos, você precisará fazer uma verificação de byte a byte. Isso é verdade, independentemente do algoritmo de hash escolhido, sempre há a possibilidade de uma colisão.
PaulG

6
@Ranhiru. Releia esta resposta, ela é a mais abrangente aqui. O hash pode ser usado como uma primeira etapa, o que garante 99,99% e% de certeza de que os arquivos são idênticos, mas se você quiser ter 100% de certeza, precisará fazer uma verificação de byte por byte. Isso é verdade se você usa MD5, SHA ou qualquer outro algoritmo.
PaulG

7
Esta resposta está errada. Prevenção de adulteração e verificação de exclusividade são a mesma coisa. Além disso, enquanto o hash não garante exclusividade, nem a comparação real. De fato, a probabilidade de um hash colidir acidentalmente é realmente menor do que a probabilidade da comparação falhar devido a falhas na CPU geradas por emissões normais de raios gama solares. E não esqueça que muitas vezes a única fonte do arquivo está do outro lado do mundo dentro de um servidor da Web, e a única informação independente que você tem para fins de comparação é o hash.
Marcelo Cantos

8
@Marcelo. Não é de raciocínio lógico que a colisão acidental seja menos provável do que as inversões acidentais de bits (enquanto faz uma comparação de byte por byte). Você ainda tem a mesma chance de troca de bits ao criar o hash (e sem dúvida mais porque há mais tempo de processamento envolvido). A @Thomas levantou a questão originalmente para sugerir que não há uma maneira garantida de identificar a exclusividade, embora o impacto das oscilações de bits seja altamente discutível. A estimativa mais pessimista é de 1 flip por GB / hora, e a RAM do ECC removeria mesmo isso.
PaulG

2
"a probabilidade de um hash acidentalmente colidir é realmente menor que a probabilidade da comparação a falhar devido a falhas no processador gerado por emissões normais de raios gama solar" [citação necessário]
endolith

20

O MD5 será bom o suficiente se você não tiver adversário. No entanto, alguém pode (propositalmente) criar dois arquivos distintos com o mesmo valor (que é chamado de colisão), e isso pode ou não ser um problema, dependendo da sua situação exata.

Como saber se as deficiências conhecidas do MD5 se aplicam a um determinado contexto é uma questão sutil, é recomendável não usar o MD5. O uso de uma função hash resistente a colisões (SHA-256 ou SHA-512) é a resposta segura. Além disso, o uso do MD5 é péssimo para relações públicas (se você usa o MD5, esteja preparado para justificar a si mesmo; enquanto ninguém questionará o uso do SHA-256).


2
Essa resposta pode ser um pouco enganadora se o leitor não estiver muito familiarizado com o hash. Não há nada mágico no SHA que evite colisões de hash, elas são apenas mais resistentes a ataques de colisão de hash . Se você deseja ter mais de 99,999% de certeza de que os arquivos são idênticos, você ainda precisará de uma verificação de byte a byte.
PaulG

7
Na verdade, uma comparação de byte a byte pode falhar devido a um raio cósmico girando um pouco (por exemplo, transformando a return 0;em a return 1;). Isso é altamente improvável, mas o risco de uma colisão com o SHA-256 é ainda menor que isso. Matematicamente, você não pode ter certeza de que dois arquivos que têm o mesmo valor de hash são idênticos, mas não pode ter certeza disso, comparando os próprios arquivos, desde que use um computador para a comparação. O que quero dizer é que não faz sentido ir além da segurança de 99.999 .... 9%, e o SHA-256 já fornece mais do que isso.
Thomas Pornin 27/10/10

2
Você não usa memória ECC? ;). Bom comentário, pensamentos muito interessantes.
PaulG 27/10/10

1
Não se esqueça do chapéu de lata! Mais seriamente, como você conhece esses factóides sobre colisões e verificou isso de alguma maneira?
James P.

@ThomasPornin Os desvios de bits cósmicos também afetariam o método MD5, por isso é ainda pior.
Endolith

9

Um MD5 pode produzir colisões. Teoricamente, embora altamente improvável, um milhão de arquivos seguidos pode produzir o mesmo hash. Não teste sua sorte e verifique se há colisões MD5 antes de armazenar o valor.

Pessoalmente, gosto de criar md5 de seqüências aleatórias, o que reduz a sobrecarga do hash de arquivos grandes. Quando colisões são encontradas, eu itero e re-hash com o contador de loop anexado.

Você pode ler sobre o princípio do buraco de pombo .


6

Eu não recomendaria. Se o aplicativo funcionasse em um sistema multiusuário, poderia haver um usuário que tivesse dois arquivos com o mesmo hash md5 (ele pode ser engenheiro e jogar com esses arquivos ou apenas ficar curioso - eles podem ser baixados facilmente de http: / /www2.mat.dtu.dk/people/S.Thomsen/wangmd5/samples.html , eu mesmo, ao escrever esta resposta, baixei duas amostras). Outra coisa é que alguns aplicativos podem armazenar essas duplicatas por qualquer motivo (não tenho certeza, se existem aplicativos, mas existe a possibilidade).

Se você estiver identificando exclusivamente os arquivos gerados pelo seu programa, eu diria que não há problema em usar o MD5. Caso contrário, eu recomendaria qualquer outra função de hash onde nenhuma colisão ainda seja conhecida.


2

Pessoalmente, acho que as pessoas usam somas de verificação brutas (escolha seu método) de outros objetos para agirem como identificadores únicos demais quando realmente querem fazer é ter identificadores únicos. A impressão digital de um objeto para esse uso não era a intenção e provavelmente requer mais reflexão do que o uso de um mecanismo de integridade semelhante ou uuid.


0

O MD5 foi quebrado, você pode usar o SHA1 (implementado na maioria dos idiomas)


Esta é uma resposta perfeitamente boa. O MD5 é inaceitável para casos de uso em Direito e Contabilidade na Europa a partir de maio de 2018.
Bert Sinnema

@BertSinnema, você poderia me indicar a fonte que define quais funções de hash são aceitáveis ​​etc., por favor?
22418

@GregSchmit talvez porque o OP não se preocupou com a força criptográfica em si. Entendi a pergunta como "Eu já uso o MD5 em um contexto não relacionado à segurança. Preciso gastar tempo para atualizar o código?" tipo de coisa. E, nesse contexto, a resposta provavelmente estava errada e o SHA1 também foi quebrado desde então.
precisa

0

Ao fazer o hash de strings curtas (<alguns K?) (Ou arquivos), é possível criar duas chaves de hash md5, uma para a string real e uma segunda para o reverso da string concatenada com uma string assimétrica curta. Exemplo: md5 (reverso (sequência || '1010')). A adição da cadeia extra garante que mesmo os arquivos compostos por uma série de bits idênticos gerem duas chaves diferentes. Por favor, entenda que mesmo sob esse esquema, existe uma chance teórica de as duas chaves de hash serem idênticas para seqüências de caracteres não idênticas, mas a probabilidade parece extremamente pequena - algo na ordem do quadrado da probabilidade de colisão md5 única e economia de tempo pode ser considerável quando o número de arquivos estiver aumentando. Esquemas mais elaborados para criar a segunda string também podem ser considerados,

Para verificar colisões, pode-se executar este teste quanto à exclusividade das chaves de hash md5 para todos os bit_vectors em um banco de dados:

selecione md5 (bit_vector), count (*), bit_and (bit_vector) do db com o
grupo bit_vector por md5 (bit_vector), bit_vector com bit_and (bit_vector) <> bit_vector


Idéia inteligente. Se um "invasor" criar um arquivo falso com o mesmo hash md5, isso não ajudará, a menos que ele conheça sua "salga", e reverter o conteúdo criaria um hash diferente. Usar 2 chaves md5 como essa reduziria muito as chances. Se for apenas para impedir um "ataque" usando um sal antes de calcular localmente, será suficiente.
precisa saber é o seguinte

0

Eu gosto de pensar no MD5 como um indicador de probabilidade ao armazenar uma grande quantidade de dados de arquivos.

Se os hashes forem iguais, então eu sei que tenho que comparar os arquivos byte a byte, mas isso pode acontecer apenas algumas vezes por um motivo falso, caso contrário (os hashes não são iguais), posso ter certeza de que estamos falando de dois arquivos diferentes .

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.