O que realmente aconteceria se eu tivesse uma colisão de hash enquanto usava o git?

Por exemplo, eu consigo confirmar dois arquivos com a mesma soma de verificação sha1, o git notaria ou corromperia um dos arquivos?

O git poderia ser aprimorado para conviver com isso ou eu precisaria mudar para um novo algoritmo de hash?

(Por favor, não desvie esta pergunta discutindo o quão improvável é isso - Obrigado)

Escolhendo átomos em 10 luas

Um hash SHA-1 é uma cadeia de 40 caracteres hexadecimais ... ou seja, 4 bits por caractere vezes 40 ... 160 bits. Agora sabemos que 10 bits é aproximadamente 1000 (1024 para ser exato), o que significa que existem 1 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 diferentes SHA-1 hashes ... 10 ⁴⁸ .

O que é isso equivalente? Bem, a Lua é composta de cerca de 10 ⁴⁷ átomos. Então, se tivermos 10 luas ... e você escolher aleatoriamente um átomo em uma dessas luas ... e então seguir em frente e escolher um átomo aleatório novamente ... então a probabilidade de você escolher o mesmo átomo duas vezes , é a probabilidade de dois confirmados git terem o mesmo hash SHA-1.

Expandindo isso, podemos fazer a pergunta ...

De quantos commits você precisa em um repositório antes de começar a se preocupar com colisões?

Isso se refere aos chamados "ataques de aniversário", que por sua vez se referem ao "Paradoxo de aniversário" ou "Problema de aniversário", que afirma que quando você escolhe aleatoriamente um determinado conjunto, você precisa surpreendentemente de algumas escolhas antes de ter mais probabilidade do que não ter escolhido algo duas vezes. Mas "surpreendentemente poucos" é um termo muito relativo aqui.

A Wikipedia possui uma tabela com probabilidade de colisões de Paradoxo de Aniversário . Não há entrada para um hash de 40 caracteres. Mas uma interpolação das entradas para 32 e 48 caracteres nos coloca no intervalo de 5 * 10 ²² git confirma para uma probabilidade de 0,1% de uma colisão. São cinquenta bilhões de bilhões de commits diferentes, ou cinquenta zettacomits , antes de você ter uma chance de 0,1% de colisão.

A soma de bytes dos hashes para esses commits seria mais dados do que todos os dados gerados na Terra por um ano, ou seja, você precisaria produzir código mais rapidamente do que o YouTube transmite o vídeo. Boa sorte com isso. : D

O ponto disso é que, a menos que alguém cause deliberadamente uma colisão, a probabilidade de ocorrer aleatoriamente é tão incrivelmente pequena que você pode ignorar esse problema

"Mas quando uma colisão não ocorrer, então o que realmente acontece?"

Ok, suponha que o improvável aconteça ou que alguém tenha conseguido adaptar uma colisão deliberada de hash SHA-1 . O que acontece depois?

Nesse caso, há uma excelente resposta em que alguém experimentou . Vou citar essa resposta:

1. Se já existir um blob com o mesmo hash, você não receberá nenhum aviso. Tudo parece estar bem, mas quando você pressiona, alguém clona ou reverte, você perde a versão mais recente (de acordo com o explicado acima).
2. Se um objeto em árvore já existir e você criar um blob com o mesmo hash: tudo parecerá normal, até você tentar empurrar ou alguém clonar seu repositório. Então você verá que o repositório está corrompido.
3. Se um objeto de confirmação já existe e você cria um blob com o mesmo hash: o mesmo que o número 2 - corrompido
4. Se um blob já existir e você criar um objeto de confirmação com o mesmo hash, ele falhará ao atualizar o "ref".
5. Se já existir um blob e você criar um objeto de árvore com o mesmo hash. Falha ao criar a confirmação.
6. Se um objeto em árvore já existir e você fizer um objeto de confirmação com o mesmo hash, ele falhará ao atualizar o "ref".
7. Se um objeto em árvore já existir e você criar um objeto em árvore com o mesmo hash, tudo parecerá correto. Mas quando você confirma, todo o repositório faz referência à árvore errada.
8. Se um objeto de confirmação já existir e você criar um objeto de confirmação com o mesmo hash, tudo parecerá correto. Mas quando você confirma, a confirmação nunca será criada e o ponteiro HEAD será movido para uma confirmação antiga.
9. Se um objeto de confirmação já existir e você criar um objeto de árvore com o mesmo hash, ele falhará ao criar o commit.

Como você pode parecer, alguns casos não são bons. Especialmente os casos 2 e 3 atrapalham seu repositório. No entanto, parece que a falha permanece nesse repositório e a improbabilidade de ataque / bizarro não se propaga para outros reposistórios.

Também parece que o problema de colisões deliberadas está sendo reconhecido como uma ameaça real e, por exemplo, o GitHub está tomando medidas para evitá-lo .

Se dois arquivos tiverem a mesma soma de hash no git, os arquivos serão tratados como idênticos. No caso absolutamente improvável de que isso aconteça, você sempre pode voltar um commit e alterar algo no arquivo para que não colidam mais ...

Veja a publicação de Linus Torvalds no tópico "Começando a pensar em sha-256?" na lista de correio do git .

Não é realmente possível responder a esta pergunta com o "mas" certo, sem também explicar por que não é um problema. Não é possível fazer isso sem realmente ter uma boa noção do que realmente é um hash. É mais complicado do que os casos simples aos quais você pode ter sido exposto em um programa de CS.

Há um mal-entendido básico da teoria da informação aqui. Se você reduzir uma grande quantidade de informações em uma quantidade menor, descartando alguma quantidade (ou seja, um hash), haverá uma chance de colisão diretamente relacionada ao comprimento dos dados. Quanto mais curtos os dados, menor será a probabilidade. Agora, a grande maioria das colisões será sem sentido, tornando-as muito mais propensas a acontecer (você nunca verificaria sem sentido ... até mesmo uma imagem binária é um pouco estruturada). No final, as chances são remotas. Para responder sua pergunta, sim, o git irá tratá-las da mesma forma, alterar o algoritmo de hash não ajudará, será necessário um "segundo cheque" de algum tipo, mas, em última análise, você precisará de tantos dados "adicionais" como o comprimento dos dados para ter 100% de certeza ... lembre-se de que você seria 99,99999 .... para um número realmente longo de dígitos ... com uma verificação simples, como você descreve. SHA-x são hashes criptograficamente fortes, o que significa que geralmente não é difícil criar intencionalmente dois conjuntos de dados de origem MUITO SEMELHANTES entre si e com o mesmo hash. Um pouco de alteração nos dados deve criar mais de um (de preferência o máximo possível) bits de saída na saída de hash, o que também significa que é muito difícil (mas não completamente impossível) retroceder do hash para o conjunto completo de colisões e, assim, retira a mensagem original desse conjunto de colisões - todas, exceto algumas, serão sem sentido e, dentre as que não são, ainda há um grande número a ser analisado se o tamanho da mensagem for significativo. A desvantagem de um hash de criptografia é que eles são lentos em calcular ... em geral.

Então, o que tudo isso significa para o Git? Não muito. Os hashes são feitos tão raramente (em relação a todo o resto) que sua penalidade computacional é baixa em geral nas operações. As chances de atingir um par de colisões são tão baixas que não é uma chance realista de ocorrer e não ser detectada imediatamente (ou seja, é provável que seu código pare de construir de repente), permitindo que o usuário corrija o problema (faça backup de uma revisão, e faça a alteração novamente, e você quase certamente obterá um hash diferente por causa da mudança de horário, que também alimenta o hash no git). É mais provável que seja um problema real para você, se você estiver armazenando binários arbitrários no git, que não é exatamente o que é o modelo de uso principal. Se você quiser fazer isso ... provavelmente está melhor usando um banco de dados tradicional.

Não é errado pensar sobre isso - é uma boa pergunta que muitas pessoas passam como "tão improvável que não vale a pena pensar" - mas é realmente um pouco mais complicado que isso. Se isso acontecer, deve ser facilmente detectável, não será uma corrupção silenciosa em um fluxo de trabalho normal.

O git poderia ser aprimorado para conviver com isso ou eu precisaria mudar para um novo algoritmo de hash?

As colisões são possíveis para qualquer algoritmo de hash, portanto, alterar a função de hash não exclui o problema, apenas torna menos provável a ocorrência. Portanto, você deve escolher uma função hash realmente boa (o SHA-1 já é, mas você pediu para não ser informado :)

Você pode ver um bom estudo em " Como o Git lidaria com uma colisão de SHA-1 em um blob? ".

Como agora é possível uma colisão SHA1 (como referencio nesta resposta com shattered.io ), saiba que o Git 2.13 (Q2 2017) melhorará / mitigará a situação atual com uma variante "detectar tentativa de criar colisões" da implementação do SHA-1 por Marc Stevens (CWI) e Dan Shumow (Microsoft) .

Consulte commit f5f5e7f , commit 8325e43 , commit c0c2006 , commit 45a574e , commit 28dc98e (16 de março de 2017) por Jeff King ( peff) .
^{(Mesclado por Junio ​​C Hamano - gitster- na confirmação 48b3693 , 24 de março de 2017)}

Makefile: faça DC_SHA1o padrão

Costumávamos usar a implementação SHA1 da biblioteca OpenSSL por padrão.
Como estamos tentando ser cuidadosos contra ataques de colisão após o recente anúncio "quebrado", mude o padrão para incentivar as pessoas a usar a implementação DC_SHA1.
Quem quiser usar a implementação do OpenSSL pode solicitá-la explicitamente OPENSSL_SHA1=YesPleaseao executar " make".

Na verdade, não temos uma colisão de objetos Git, então o melhor que podemos fazer é executar um dos PDFs quebrados através do teste-sha1. Isso deve acionar a verificação de colisão e morrer.

O Git poderia ser aprimorado para conviver com isso ou eu precisaria mudar para um novo algoritmo de hash?

Atualização em dezembro de 2017 com o Git 2.16 (primeiro trimestre de 2018): este esforço para oferecer suporte a um SHA alternativo está em andamento: consulte " Por que o Git não usa o SHA mais moderno? ".

Você poderá usar outro algoritmo de hash: o SHA1 não é mais o único para o Git.

O Git 2.18 (Q2 2018) documenta esse processo.

Consulte commit 5988eb6 , commit 45fa195 (26 de março de 2018) por Ævar Arnfjörð Bjarmason ( avar) .
^{(Incorporado por Junio ​​C Hamano - gitster- in commit d877975 , 11 de abril de 2018)}

doc hash-function-transition: esclarecer o que significa SHAttered

Tente esclarecer o que o ataque SHAttered significa na prática para o Git.
A versão anterior do texto não fez nenhuma menção ao Git que já possui uma atenuação para esse ataque específico, que, segundo os pesquisadores da SHAttered, detectará ataques de colisão criptoanalítica.

Talvez eu tenha entendido errado algumas das nuances, mas, até onde sei, este novo texto resume com precisão a situação atual do SHA-1 no git. Ou seja, o git não usa mais o SHA-1, ele usa o Hardened-SHA-1 (eles produzem as mesmas saídas 99.99999999999 ...% do tempo).

Assim, o texto anterior estava incorreto ao afirmar que:

[...] Como resultado [do SHAttered], o SHA-1 não pode mais ser considerado criptograficamente seguro [...]

Esse não é o caso. Temos uma mitigação contra o SHAttered, no entanto , consideramos prudente avançar para uma NewHashfutura vulnerabilidade no SHA-1 ou no Hardened-SHA-1.

Portanto, a nova documentação agora diz:

O Git v2.13.0 e posterior posteriormente foram movidos para uma implementação SHA-1 reforçada por padrão, que não é vulnerável ao ataque destruído por SHAttered.

Portanto, o Git já migrou para um novo hash que não é o SHA-1 e não compartilha suas vulnerabilidades, sua nova função de hash produz exatamente a mesma saída para todas as entradas conhecidas, exceto dois PDFs publicados pelo SHAttered pesquisadores, e a nova implementação (escrita por esses pesquisadores) afirma detectar futuros ataques de colisão criptoanalítica.

Independentemente disso, é prudente passar de qualquer variante do SHA-1 para um novo hash. Não há garantia de que futuros ataques ao SHA-1 não serão publicados no futuro, e esses ataques podem não ter atenuações viáveis.

Se o SHA-1 e suas variantes fossem realmente quebrados, a função hash do Git não poderia mais ser considerada criptograficamente segura. Isso afetaria a comunicação dos valores de hash, porque não poderíamos confiar que um determinado valor de hash representasse a boa versão conhecida do conteúdo que o orador pretendia.

Nota: esse mesmo documento agora (Q3 2018, Git 2.19) faz referência explícita ao "novo hash" como SHA-256 : consulte " Por que o Git não usa SHA mais moderno? ".

O Google agora alega que a colisão com SHA-1 é possível sob certas condições prévias: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Como o git usa o SHA-1 para verificar a integridade do arquivo, isso significa que a integridade do arquivo no git está comprometida.

Na IMO, o git deve definitivamente usar um algoritmo de hash melhor, já que agora é possível uma colisão deliberada.

Uma colisão de hash é tão altamente improvável que é pura surpresa! Cientistas de todo o mundo estão tentando conseguir um, mas ainda não conseguiram. Para certos algoritmos, como o MD5, eles conseguiram.

Quais são as hipóteses?

O SHA-256 possui 2 ^ 256 possíveis hashes. Isso é cerca de 10 ^ 78 . Ou, para ser mais gráfico, as chances de uma colisão são de aproximadamente

1: 100 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000

A chance de ganhar na loteria é de cerca de 1: 14 milhões . A chance de uma colisão com o SHA-256 é como ganhar na loteria em 11 dias consecutivos !

Explicação matemática: 14 000 000 ^ 11 ~ 2 ^ 256

Além disso, o universo possui cerca de 10 ^ 80 átomos. Isso é apenas 100 vezes mais do que existem combinações SHA-256.

Colisão MD5 bem sucedida

Mesmo para o MD5, as chances são pequenas. Porém, matemáticos conseguiram criar uma colisão:

d131dd02c5e6eec4 693d9a0698aff95c 2fcab5 8 712467eab 4004583eb8fb7f89
55ad340609f4b302 83e4888325 7 1415a 085125e8f7cdc99f d91dbdf280373c5b
d8823e3156348f5b ae6dacd436c919c6 dd53e2 b 487da03fd 02396306d248cda0
e99f33420f577ee8 ce54b67080 a 80d1e c69821bcb6a88393 96f965 2 b6ff72a70

tem o mesmo MD5 que

d131dd02c5e6eec4 693d9a0698aff95c 2fcab5 0 712467eab 4004583eb8fb7f89
55ad340609f4b302 83e4888325 f 1415a 085125e8f7cdc99f d91dbd7280373c5b
d8823e3156348f5b ae6dacd436c919c6 dd53e2 3 487da03fd 02396306d248cda0
e99f33420f577ee8 ce54b67080 2 80d1e c69821bcb6a88393 96f965 a b6ff72a70

Isso não significa que o MD5 esteja menos seguro agora que seu algoritmo está quebrado. Você pode criar colisões MD5 de propósito, mas a chance de uma colisão MD5 acidental ainda é 2 ^ 128, o que ainda é muito.

Conclusão

Você não precisa se preocupar com colisões. Os algoritmos de hash são a segunda maneira mais segura de verificar a uniformidade do arquivo. A única maneira mais segura é uma comparação binária.

Bem, acho que agora sabemos o que aconteceria - você deve esperar que seu repositório fique corrompido ( fonte ).

Encontrei recentemente uma postagem de 29/04/2013 em um grupo de discussão do BSD em

http://openbsd-archive.7691.n7.nabble.com/Why-does-OpenBSD-use-CVS-td226952.html

onde o cartaz afirma:

Eu tive uma colisão de hash uma vez, usando o git rebase.

Infelizmente, ele não fornece provas para sua reivindicação. Mas talvez você queira tentar entrar em contato com ele e perguntar sobre esse suposto incidente.

Porém, em um nível mais geral, devido ao ataque de aniversário, a chance de uma colisão de hash SHA-1 é de 1 em pow (2, 80).

Isso soa muito e certamente é muito mais do que o número total de versões de arquivos individuais presentes em todos os repositórios Git do mundo juntos.

No entanto, isso se aplica apenas às versões que realmente permanecem no histórico de versões.

Se um desenvolvedor depende muito de rebasing, toda vez que uma rebase é executada para uma ramificação, todas as confirmações em todas as versões dessa ramificação (ou parte rebastada da ramificação) recebem novos hashes. O mesmo vale para todos os arquivos modificados com "git filter-branch". Portanto, "rebase" e "ramificação de filtro" podem ser grandes multiplicadores para o número de hashes gerados ao longo do tempo, mesmo que nem todos sejam realmente mantidos: Freqüentemente, após a rebasagem (especialmente com a finalidade de "limpar" uma ramificação ), o ramo original é jogado fora.

Mas se a colisão ocorrer durante o rebase ou a ramificação do filtro, ainda poderá ter efeitos adversos.

Outra coisa seria estimar o número total de entidades com hash nos repositórios git e ver a que distância estão do pow (2, 80).

Digamos que temos cerca de 8 bilhões de pessoas, e todas elas executariam o git e manteriam suas versões em repositórios de 100 git por pessoa. Vamos assumir ainda que o repositório médio possui 100 confirmações e 10 arquivos, e apenas um desses arquivos é alterado por confirmação.

Para cada revisão, temos pelo menos um hash para o objeto em árvore e o próprio objeto de confirmação. Juntamente com o arquivo alterado, temos 3 hashes por revisão e, portanto, 300 hashes por repositório.

Para 100 repositórios de 8 bilhões de pessoas, isso gera pow (2, 47), que ainda está longe de pow (2, 80).

No entanto, isso não inclui o suposto efeito de multiplicação mencionado acima, porque não sei como incluí-lo nessa estimativa. Talvez isso possa aumentar consideravelmente as chances de uma colisão. Especialmente se repositórios muito grandes, com um histórico de consolidação longo (como o Linux Kernel), são reprovados por muitas pessoas para pequenas alterações, que, no entanto, criam hashes diferentes para todos os commit afetados.