Para adicionar à minha resposta anterior de 2012 , existe agora (fevereiro de 2017, cinco anos depois), um exemplo de colisão SHA-1 com shattered.io , onde você pode criar dois arquivos PDF em colisão: que é obter um SHA- 1 assinatura digital no primeiro arquivo PDF que também pode ser abusada como uma assinatura válida no segundo arquivo PDF.
Veja também " À porta da morte há anos, a função SHA1 amplamente utilizada agora está morta ", e esta ilustração .
Atualização 26 de fevereiro: Linus confirmou os seguintes pontos em uma postagem do Google+ :
(1) Primeiro - o céu não está caindo. Há uma grande diferença entre usar um hash criptográfico para coisas como assinatura de segurança e usar um para gerar um "identificador de conteúdo" para um sistema endereçável como o git.
(2) Em segundo lugar, a natureza desse ataque SHA1 específico significa que é realmente muito fácil mitigar, e já houve dois conjuntos de patches publicados para essa mitigação.
(3) E, finalmente, há realmente uma transição razoavelmente direta para algum outro hash que não quebrará o mundo - ou até mesmo repositórios git antigos.
Sobre essa transição, consulte o primeiro trimestre de 2018 Git 2.16 adicionando uma estrutura representando o algoritmo de hash. A implementação dessa transição foi iniciada.
Iniciando o Git 2.19 (terceiro trimestre de 2018) , o Git escolheu SHA-256 como NewHash e está no processo de integrá-lo ao código (o que significa que o SHA1 ainda é o padrão (Q2 2019, Git 2.21), mas o SHA2 será o sucessor)
Resposta original (25 de fevereiro) Mas:
- Isso permite forjar um blob, no entanto, o SHA-1 da árvore ainda muda, pois o tamanho do blob forjado pode não ser o mesmo que o original: consulte " Como é calculado o hash do git? "; um blob SHA1 é calculado com base no conteúdo e tamanho .
Ele tem algum problema para git-svn
que . Ou melhor, com o próprio svn , como pode visto aqui .
- Como mencionei na minha resposta original , o custo dessa tentativa ainda é proibitivo por enquanto (6.500 anos de CPU e 100 anos de GPU). Veja também Valerie Anita Aurora em " Vida útil das funções de hash criptográfico ".
- Como comentado anteriormente, não se trata de segurança ou confiança, mas da integridade dos dados (deduplicação e detecção de erros) que podem ser facilmente detectados por um
git fsck
, conforme mencionado hoje por Linus Torvalds . git fsck
alertaria sobre uma mensagem de confirmação com dados opacos ocultos após a NUL
(embora NUL
nem sempre esteja presente em um arquivo fraudulento ).
Nem todo mundo liga transfer.fsck
, mas o GitHub faz: qualquer push será abortado no caso de um objeto malformado ou um link quebrado. Embora ... haja um motivo para isso não ser ativado por padrão .
- um arquivo pdf pode ter dados binários arbitrários que você pode alterar para gerar um SHA-1 em colisão, em oposição ao código-fonte forjado.
O problema real na criação de dois repositórios Git com o mesmo cabeçalho de confirmação de hash e conteúdos diferentes. E mesmo assim, o ataque continua complicado .
- Linus acrescenta :
O ponto principal de um SCM é que não se trata de um evento único, mas de um histórico contínuo. Isso também significa fundamentalmente que um ataque bem-sucedido precisa funcionar com o tempo e não ser detectável.
Se você consegue enganar um SCM uma vez, insira seu código e ele é detectado na próxima semana, você não fez nada de útil. Você só se queimou.
Joey Hess experimenta esses pdf em um repositório Git e descobriu :
Isso inclui dois arquivos com o mesmo SHA e tamanho, que recebem blobs diferentes, graças à maneira como o git anexa o cabeçalho ao conteúdo.
joey@darkstar:~/tmp/supercollider>sha1sum bad.pdf good.pdf
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a bad.pdf
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a good.pdf
joey@darkstar:~/tmp/supercollider>git ls-tree HEAD
100644 blob ca44e9913faf08d625346205e228e2265dd12b65 bad.pdf
100644 blob 5f90b67523865ad5b1391cb4a1c010d541c816c1 good.pdf
Enquanto o acréscimo de dados idênticos a esses arquivos em colisão gera outras colisões, o acréscimo de dados não.
Portanto, o principal vetor de ataque (forjando um commit) seria :
- Gere um objeto de confirmação regular;
- use o objeto de confirmação inteiro + NUL como o prefixo escolhido e
- use o ataque de colisão com prefixo idêntico para gerar os objetos bons / ruins em colisão.
- ... e isso é inútil porque os objetos de confirmação bons e ruins ainda apontam para a mesma árvore!
Além disso, você já pode e detecta ataques de colisão criptoanalítica contra o SHA-1 presente em cada arquivo com cr-marcstevens/sha1collisiondetection
Adicionar uma verificação semelhante no próprio Git teria algum custo de computação .
Sobre a alteração de hash, o Linux comenta :
O tamanho do hash e a escolha do algoritmo de hash são problemas independentes.
O que você provavelmente faria é mudar para um hash de 256 bits, usá-lo internamente e no banco de dados nativo do git e, por padrão, mostrar apenas
o hash como uma sequência hexadecimal de 40 caracteres (tipo como já abreviamos as coisas em muitas situações).
Dessa forma, as ferramentas em torno do git nem veem a mudança, a menos que sejam aprovadas em algum --full-hash
argumento " " especial (ou " --abbrev=64
" ou qualquer outra coisa - o padrão é que abreviamos para 40).
Ainda assim, um plano de transição (do SHA1 para outra função de hash) ainda seria complexo , mas estudado ativamente.
Uma convert-to-object_id
campanha está em andamento :
Atualização 20 de março: O GitHub detalha um possível ataque e sua proteção :
Os nomes SHA-1 podem receber confiança confiada através de vários mecanismos. Por exemplo, o Git permite que você assine criptograficamente um commit ou tag. Fazer isso assina apenas o próprio objeto de confirmação ou marcação, que por sua vez aponta para outros objetos que contêm os dados reais do arquivo usando seus nomes SHA-1. Uma colisão nesses objetos pode produzir uma assinatura que pareça válida, mas que aponte para dados diferentes do que o signatário pretendeu. Nesse ataque, o assinante vê apenas metade da colisão e a vítima vê a outra metade.
Proteção:
O ataque recente usa técnicas especiais para explorar pontos fracos no algoritmo SHA-1 que encontram uma colisão em muito menos tempo. Essas técnicas deixam um padrão nos bytes que podem ser detectados ao calcular o SHA-1 de qualquer metade de um par em colisão.
Agora, o GitHub.com realiza essa detecção para cada SHA-1 calculado e interrompe a operação se houver evidência de que o objeto é metade de um par em colisão. Isso impede que os invasores usem o GitHub para convencer um projeto a aceitar a metade "inocente" de sua colisão, além de impedir que eles hospedem a metade maliciosa.
Ver " sha1collisiondetection
" por Marc Stevens
Novamente, com o primeiro trimestre de 2018 Git 2.16 adicionando uma estrutura representando o algoritmo de hash, a implementação de uma transição para um novo hash foi iniciada.
Como mencionado acima, o novo Hash suportado será o SHA-256 .