Colisão de hash no git

175

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)

git hash sha1 hash-collision Sec
fonte
26
I've been informed by the git Gods that the chances of a SHA1 collision is the same as the Earth being sucked up into the black hole created by the CERN accelerator. If this is indeed true, then there's no need for that extra memcmp. , fonte: lwn.net/Articles/307281
KurzedMetal
16
ABSOLUTAMENTE NÃO ASSIM. Para citar Dan Bernstein: "O fato de os acadêmicos não terem realizado o ataque de colisão SHA-1 ainda é um acidente histórico menor" - agora que o concurso SHA-3 terminou, há uma boa chance de que as pessoas relevantes voltem sua atenção a usar o ataque conhecido para produzir uma colisão. Marc Stevens estima a dificuldade como meras 2 ^ 61 operações. Muito provavelmente haverá uma colisão com SHA-1 em breve; é estranho que ainda não tenha acontecido.
Paul Crowley
27
@KurzedMetal: Há uma chance de criar um buraco negro no CERN (dois prótons colidiriam com precisão (10 ^ -15m)), no entanto, esse buraco negro não sugaria a Terra, evaporaria instantaneamente devido à radiação Hawking ... as chances de colisão SHA1 são muito maiores do que está sendo sugado ... apenas dizendo ...
Jaa-c
9
possível duplicata de Como o git lidaria com uma colisão SHA-1 em um blob?
meagar
17
É surpreendente que você tenha pedido especificamente às pessoas que não discutissem a improbabilidade da colisão com o git, e quase todo mundo falava sobre a improbabilidade da colisão com o git. Essas pessoas devem ser banidas do stackoverflow por toda a vida!
Yukio Fukuzawa

Respostas:

108

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 48 .

O que é isso equivalente? Bem, a Lua é composta de cerca de 10 47 á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 22 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 .

MichaelK
fonte
22
Eu não sei se os números são precisos, mas Gosh esta é uma ótima maneira gráfica para descrever a improbabilidade, e engraçado :)
mimoralea
4
Estou em contato com a NASA agora para encontrar 10 luas e experimentá-lo. A menos que tenhamos 10 luas, ninguém dizer se ele funciona;)
Utkarsh Kumar
2
A chance de uma consolidação aleatória de um arquivo de texto real ser tão boa quanto zero, muito improvável. Mas essa resposta ignora completamente o fato de que alguém poderia tentar deliberadamente criar uma colisão. Com o hash SHA-1 sob ataque, isso está se tornando um fator bastante importante.
Maarten Bodewes 24/03
7
Motivo da votação para baixo: Muito bem dito, mas a probabilidade não significa absolutamente nada aqui. Você pode dizer o mesmo sobre ganhar na loteria, mas as pessoas ganham loteria aqui e ali diariamente. Portanto, a empresa de loteria não pode apenas dizer: a chance é pequena, então não devemos nos preocupar em pagar o jackpot. A pergunta do OP aqui é: o que acontece quando essa pequena chance ocorre e você não respondeu.
Yukio Fukuzawa
3
@FukuzawaYukio No entanto, não existem 2 ^ 48 bilhetes de loteria impressos - apenas milhões (talvez 200 milhões no total por ano ... quem sabe?), E há uma loteria vencedora. A probabilidade é muito maior e, para alguns bilhetes de loteria, o bilhete vencedor é sempre impresso; portanto, o vencedor é inevitável (a menos que o bilhete vencedor seja extraviado acidentalmente). Além disso, fiz um jogo pseudo-realista de bilhete de loteria há muitos anos: lottery.py . Escusado será dizer que você perde 99% do tempo.
dylnmc
67

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 .

klaustopher
fonte
4
"Se dois arquivos tiverem a mesma soma de hash no git, os arquivos serão tratados como idênticos." Esta é realmente uma resposta adequada. No entanto, você tem alguma fonte para esta declaração klaustopher? Seu link não está funcionando para mim.
Tiago
3
Mas isso não é absolutamente improvável se você trabalhar em um projeto com uma coleção de amostras de colisão de hash.
Doomjunky
6
@JBishop Não, não foi. Se você tiver uma prova de colisão de hash, terá fama instantânea. Não se esqueça de publicá-lo! Vou enviar uma caixa de cerveja Haarlem realmente boa se você me mostrar uma colisão de hash SHA-1 em tamanho grande criada no Git dentro de uma semana. Observe que deve ser uma colisão de hash separada, não uma já citada em outro lugar (não que alguém tenha postado uma ainda, mas ainda assim).
Maarten Bodewes 24/03
7
+1 A única resposta até agora que realmente responde à pergunta. Todo o resto está apenas falando sobre a "pequena chance" que isso pode ocorrer, que todo desenvolvedor já conhece.
Yukio Fukuzawa
2
Seja muito cauteloso com Linus sobre a segurança de TI - ele já se enganou antes e se enganou quanto a isso. Se alguém puder criar colisões com o SHA-1 à vontade, poderá usá-lo para todo tipo de confusão, como criar históricos circulares que causam falhas nos servidores e clientes do Git.
DomQ
26

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.

Steve
fonte
4
you'll almost certainly get a different hash because of the time change, which also feeds the hash in gitO hash não é baseado apenas no conteúdo de um arquivo?
Fredoverflow 15/02
4
O hash de um blob é baseado no conteúdo de um arquivo (com um pouquinho de metadados). No entanto, o hash de um commit (que em teoria também poderia colidir) contém o horário atual e o hash da árvore, o autor, os hashes dos pais confirmam etc. No entanto, como @Steve aponta, as coisas pequenas são menos propensas a colidir, e a confirmação é uma coisa pequena.
precisa saber é o seguinte
1
Não pense que concordo com o "Quanto mais curtos os dados, menor será a probabilidade [de colisões]". Se você quer dizer hashes mais curtos, está reduzindo o conjunto de hashes possíveis = mais entradas mapeadas para cada hash = maior chance de colisão. Se você quer dizer mensagens mais curtas, hash, isso é verdade apenas no sentido de que o número de entradas possíveis é limitado pelo número de caracteres usados, o que parece tão óbvio que sinto que devo estar perdendo o seu argumento?
Basic
Eu nunca pensei no ponto "MUITO SIMILAR", que é realmente um ponto bom. Basicamente, significa que, para ter 2 confirmações com o mesmo hash, seria necessário alterar uma parte significativa dos caracteres em cada arquivo (sem mencionar os nomes, caminhos e número de arquivos).
PieterNuyts
1
@PieterNuyts Não, para obter um hash específico, de um arquivo inicial arbitrário, você normalmente precisará alterar as informações no arquivo por uma quantidade semelhante ao número de bits de informações no hash, ou seja, cerca de 160 bits para SHA-1. No entanto, as informações sobre quais bits alterar também contam aqui; portanto, quanto mais longo o arquivo, menos bits você precisará alterar se escolher os corretos. Hipoteticamente, dado um arquivo de comprimento bem acima de 2 ^ 160 bytes, você pode obter quase qualquer hash alterando um único bit, já que a localização desse bit contém mais de 160 bits de informação!
M Kloster
10

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 :)

Roberto Bonvallet
fonte
Eu acho que você quer dizer "mais improvável" ou "menos provável", certo? Claro que você pode mudar para um algoritmo de hash com menos bytes na saída, mas isso não significa, certo? :)
MichaelK
2
O SHA-1 está quebrado no sentido de que será possível criar colisões deliberadas de hash. Eu acho que já foi em 2012 também. Portanto, mudar para um hash diferente, mais seguro e com maior estado e saída, certamente faria a diferença.
Maarten Bodewes 24/03
9

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? ".

VonC
fonte
4
Esta é a única resposta decente ou comentário aqui. O resumo é - embora extremamente improvável, é possível. Eles também seriam imediatamente não identificáveis ​​e remediados através de ajustes de um arquivo (com um comentário) para evitar a colisão. Considera-se que as explorações intencionais são irrelevantes, porque alguém pode facilmente verificar "código incorreto" - e existem coisas como assinaturas e solicitações de recebimento deliberadas para impedir que pessoas aleatórias verifiquem coisas aleatórias.
21717 Brad
5

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.

Petercommand Hsu
fonte
2
Além disso, seria prudente não confiar na palavra de Linus sobre segurança de computadores. Ele já estava errado antes, e ele está errado neste. (Por exemplo, uma colisão oráculo SHA-1 permite que um criar circular cometer histórias para os servidores de colisão e clientes)
DomQ
2

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.

bytecode77
fonte
4
Essa resposta fala principalmente sobre o SHA-256, o que é irrelevante, pois a pergunta era sobre o SHA-1. A matemática que mostra a improbabilidade de uma colisão com o SHA-256 é muito mais otimista do que um SHA-1 resultaria. Ainda é muito improvável, mas uma resposta do SHA-1 teria sido mais relevante.
Andrew Arnott
@AndrewArnott Não há diferença relevante entre o SHA-256 e o ​​SHA-1. O SHA-1 é 2 ^ 128 vezes mais fraco, mas isso também não importa. Ainda não é quebrável, então minha resposta não é tão equivocada.
Bytecode77
4
O SHA-1 está realmente quebrado, então dizer que "ainda não pode ser quebrado " também está incorreto. Dado que o SHA-1 está de fato quebrado, alguém poderia atacar intencionalmente o algoritmo sha-1 do git para substituir o conteúdo sem ser detectado. O SHA-256 ainda não foi quebrado, portanto, seria mais seguro. Assim, responder a uma pergunta sobre possíveis colisões de git seria melhor mantido para o SHA-1.
Andrew Arnott 4/15
"Isso não significa que o MD5 esteja menos seguro agora que seu algoritmo está quebrado." Volte novamente? Você poderia explicar essa frase?
Maarten Bodewes 24/03
Razão da resposta: porque há muita confusão entre as pessoas que não estão familiarizadas com a computação e ainda continuam aqui pesquisando na web. Os conceitos errôneos sobre "criptografia versus poder de computação" são, na minha experiência, mais comuns do que você pensa, então eu os tratei como informações adicionais.
Bytecode77 25/05
1

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

Conor Bradley
fonte
1

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.

Guenther Brunthaler
fonte
Interessante. +1. Como mencionei acima, esse problema desaparecerá eventualmente: stackoverflow.com/a/47838703/6309
VonC