Cosa accadrebbe realmente se avessi una collisione di hash durante l'utilizzo di Git?

Ad esempio, riesco a eseguire il commit di due file con lo stesso checksum sha1, lo noterei o danneggerebbe uno dei file?

Git potrebbe essere migliorato per convivere con quello, o dovrei passare a un nuovo algoritmo di hash?

(Per favore non deviare questa domanda discutendo quanto sia improbabile - Grazie)

Raccogliere atomi su 10 Lune

Un hash SHA-1 è una stringa di 40 caratteri esadecimali ... cioè 4 bit per carattere per 40 ... 160 bit. Ora sappiamo che 10 bit sono circa 1000 (1024 per l'esattezza), il che significa che ci sono 1 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 diversi hash SHA-1 ... 10 ⁴⁸ .

In cosa consiste questo equivalente? Bene, la Luna è composta da circa 10 ⁴⁷ atomi. Quindi se abbiamo 10 Lune ... e scegli casualmente un atomo su una di queste lune ... e poi vai avanti e scegli di nuovo un atomo casuale su di loro ... quindi la probabilità che tu scelga lo stesso atomo due volte , è la probabilità che due dati git commessi abbiano lo stesso hash SHA-1.

Espandendo su questo possiamo porre la domanda ...

Di quanti commit hai bisogno in un repository prima di iniziare a preoccuparti delle collisioni?

Questo si riferisce ai cosiddetti "Attacchi di compleanno", che a loro volta si riferiscono al "Paradosso del compleanno" o "Problema di compleanno", che afferma che quando si sceglie casualmente da un determinato set, è necessario sorprendentemente poche scelte prima di essere più probabili che no aver scelto qualcosa due volte. Ma "sorprendentemente pochi" è un termine molto relativo qui.

Wikipedia ha una tabella sulla probabilità di collisioni di Paradox di compleanno . Non è disponibile alcuna voce per un hash di 40 caratteri. Ma un'interpolazione delle voci per 32 e 48 caratteri ci porta nell'intervallo di 5 * 10 ²² git si impegna per una probabilità dello 0,1% di una collisione. Si tratta di cinquantamila miliardi di miliardi di commit diversi, o di cinquanta Zettacommits , prima che tu abbia raggiunto anche una probabilità dello 0,1% di avere una collisione.

La somma in byte degli hash da soli per questi commit sarebbe più dati di tutti i dati generati sulla Terra per un anno, il che significa che dovresti sfornare il codice più velocemente di YouTube che trasmette video. Buona fortuna. : D

Il punto di ciò è che, a meno che qualcuno non stia causando deliberatamente una collisione, la probabilità che uno accada a caso è così incredibilmente piccola che puoi ignorare questo problema

"Ma quando si verifica una collisione , cosa succede realmente?"

Ok, supponiamo che accada l'improbabile, o supponiamo che qualcuno sia riuscito a personalizzare una collisione di hash SHA-1 deliberata . Cosa succede allora?

In quel caso c'è una risposta eccellente in cui qualcuno l'ha sperimentato . Citerò da quella risposta:

1. Se esiste già un BLOB con lo stesso hash, non riceverai alcun avviso. Tutto sembra andare bene, ma quando spingi, qualcuno clona o ritorni, perderai l'ultima versione (in linea con quanto spiegato sopra).
2. Se esiste già un oggetto albero e si crea un BLOB con lo stesso hash: tutto sembrerà normale, finché non si tenta di spingere o qualcuno clona il proprio repository. Quindi vedrai che il repository è danneggiato.
3. Se esiste già un oggetto commit e si crea un BLOB con lo stesso hash: uguale a # 2 - danneggiato
4. Se esiste già un BLOB e si crea un oggetto commit con lo stesso hash, fallirà durante l'aggiornamento di "ref".
5. Se esiste già un BLOB e si crea un oggetto albero con lo stesso hash. Non funzionerà durante la creazione del commit.
6. Se esiste già un oggetto ad albero e si crea un oggetto commit con lo stesso hash, fallirà durante l'aggiornamento di "ref".
7. Se esiste già un oggetto albero e si crea un oggetto albero con lo stesso hash, tutto sembrerà ok. Ma quando commetti, tutto il repository farà riferimento all'albero sbagliato.
8. Se esiste già un oggetto commit e si crea un oggetto commit con lo stesso hash, tutto sembrerà ok. Ma quando esegui il commit, il commit non verrà mai creato e il puntatore HEAD verrà spostato su un vecchio commit.
9. Se esiste già un oggetto commit e si crea un oggetto albero con lo stesso hash, fallirà durante la creazione del commit.

Come puoi sembrare, alcuni casi non vanno bene. Soprattutto i casi n. 2 e n. 3 rovinano il repository. Tuttavia, sembra che l'errore rimanga all'interno di quel repository e l'attacco / bizzarra improbabilità non si propaga ad altri repository.

Inoltre, sembra che la questione delle collisioni deliberate sia riconosciuta come una vera minaccia, e quindi ad esempio GitHub sta adottando misure per prevenirla .

Se due file hanno la stessa somma di hash in git, li tratterà come identici. Nel caso assolutamente improbabile che ciò accada, potresti sempre tornare indietro di un commit e modificare qualcosa nel file in modo che non si scontrino più ...

Vedi il post di Linus Torvalds nel thread "Iniziando a pensare a sha-256?" nella mailing list di git .

Non è davvero possibile rispondere a questa domanda con il giusto "ma" senza anche spiegare perché non è un problema. Non è possibile farlo senza avere una buona presa su ciò che è davvero un hash. È più complicato dei semplici casi a cui potresti essere stato esposto in un programma CS.

C'è un malinteso di base sulla teoria dell'informazione qui. Se riduci una grande quantità di informazioni in una quantità inferiore scartando una certa quantità (ad es. Un hash) ci sarà la possibilità di una collisione direttamente correlata alla lunghezza dei dati. Più i dati sono brevi, meno è probabile che lo siano. Ora, la stragrande maggioranza delle collisioni sarà incomprensibile, rendendole molto più probabili in realtà (non verrebbe mai verificato in modo incomprensibile ... anche un'immagine binaria è in qualche modo strutturata). Alla fine, le possibilità sono remote. Per rispondere alla tua domanda, sì, git le tratterà allo stesso modo, cambiare l'algoritmo di hash non aiuterà, ci vorrà un "secondo controllo" di qualche tipo, ma alla fine, avresti bisogno di tanti dati di "controllo aggiuntivo" dato che la lunghezza dei dati è sicura al 100% ... tieni presente che saresti 99.99999 .... a un numero davvero lungo di cifre .... certo con un semplice controllo come lo descrivi. Gli SHA-x sono hash crittograficamente potenti, il che significa che generalmente non è difficile creare intenzionalmente due set di dati di origine che sono MOLTO SIMILI tra loro e hanno lo stesso hash. Un bit di cambiamento nei dati dovrebbe creare più di uno (preferibilmente il maggior numero possibile) di bit nell'output di hash, il che significa anche che è molto difficile (ma non del tutto impossibile) tornare dall'hash al set completo di collisioni, e quindi estrarre il messaggio originale da quella serie di collisioni - tutte tranne alcune saranno incomprensibili, e tra quelle che non lo sono c'è ancora un numero enorme da esaminare se la lunghezza del messaggio è significativa. L'aspetto negativo di un hash crittografico è che sono lenti da calcolare ... in generale.

Allora, cosa significa tutto per Git? Non tanto. Gli hash vengono eseguiti così raramente (rispetto a tutto il resto) che la loro penalità computazionale è bassa nel complesso delle operazioni. Le possibilità di colpire un paio di collisioni sono così basse, non è una possibilità realistica che si verifichi e non venga rilevata immediatamente (cioè il tuo codice probabilmente smetterebbe improvvisamente di costruire), consentendo all'utente di risolvere il problema (backup di una revisione, e apportare di nuovo il cambiamento, e quasi sicuramente otterrai un hash diverso a causa del cambio di tempo, che alimenta anche l'hash in git). È più probabile che sia un vero problema per te se stai memorizzando binari arbitrari in git, che non è proprio quello che è il modello di utilizzo principale. Se vuoi farlo ... probabilmente stai meglio usando un database tradizionale.

Non è sbagliato pensare a questo - è una buona domanda che molte persone passino come "così improbabile non valga la pena pensarci" - ma è davvero un po 'più complicato di così. Se succede, dovrebbe essere facilmente rilevabile, non sarà una corruzione silenziosa in un normale flusso di lavoro.

Git potrebbe essere migliorato per convivere con quello, o dovrei passare a un nuovo algoritmo di hash?

Le collisioni sono possibili per qualsiasi algoritmo di hash, quindi la modifica della funzione hash non preclude il problema, ma rende meno probabile che accada. Quindi dovresti scegliere una funzione hash davvero buona (SHA-1 lo è già, ma hai chiesto di non dirti :)

Puoi vedere un buon studio in " Come farebbe Git a gestire una collisione SHA-1 su un blob? ".

Poiché ora è possibile una collisione SHA1 (come faccio riferimento in questa risposta con shattered.io ), sappi che Git 2.13 (2 ° trimestre 2017) migliorerà / mitigherà la situazione attuale con una variante di "rilevare il tentativo di creare collisioni" dell'implementazione SHA-1 di Marc Stevens (CWI) e Dan Shumow (Microsoft) .

Vedi commit f5f5e7f , commit 8325e43 , commit c0c2006 , commit 45a574e , commit 28dc98e (16 marzo 2017) di Jeff King ( peff) .
^{(Unita da Junio ​​C Hamano - gitster- in commit 48b3693 , 24 marzo 2017)}

Makefile: imposta DC_SHA1il valore predefinito

Per impostazione predefinita, utilizzavamo l'implementazione SHA1 dalla libreria OpenSSL.
Mentre stiamo cercando di stare attenti agli attacchi di collisione dopo il recente annuncio "frantumato", cambia l'impostazione predefinita per incoraggiare le persone a utilizzare l'implementazione DC_SHA1.
Chi desidera utilizzare l'implementazione di OpenSSL può esplicitamente richiederlo OPENSSL_SHA1=YesPleaseeseguendo " make".

In realtà non abbiamo una collisione di oggetti Git, quindi il meglio che possiamo fare è eseguire uno dei PDF in frantumi tramite test-sha1. Ciò dovrebbe innescare il controllo delle collisioni e morire.

Git potrebbe essere migliorato per convivere con quello, o dovrei passare a un nuovo algoritmo di hash?

Aggiornamento dicembre 2017 con Git 2.16 (Q1 2018): è in corso questo sforzo per supportare un SHA alternativo: vedi " Perché Git non utilizza un SHA più moderno? ".

Sarai in grado di utilizzare un altro algoritmo di hash: SHA1 non è più l'unico per Git.

Git 2.18 (Q2 2018) documenta questo processo.

Vedi commit 5988eb6 , commit 45fa195 (26 mar 2018) di Ævar Arnfjörð Bjarmason ( avar) .
^{(Unito da Junio ​​C Hamano - gitster- in commit d877975 , 11 apr 2018)}

doc hash-function-transition: chiarire cosa significa SHAttered

Tentativo di chiarire cosa significa l'attacco SHAttered in pratica per Git.
La versione precedente del testo non menzionava affatto che Git avesse già una mitigazione per questo specifico attacco, che secondo i ricercatori SHAttered rileverà attacchi di collisione crittoanalitici.

Potrei aver sbagliato alcune sfumature, ma per quanto ne so questo nuovo testo riassume accuratamente la situazione attuale con SHA-1 in git. Vale a dire che git non utilizza più SHA-1, ma utilizza Hardened-SHA-1 (semplicemente accade che producano le stesse uscite 99.99999999999 ...% delle volte).

Pertanto, il testo precedente era errato nell'affermare che:

[...] Di conseguenza [di SHAttered], SHA-1 non può più essere considerato sicuro crittograficamente [...]

Non è così. Abbiamo una mitigazione nei confronti di SHAttered, tuttavia riteniamo prudente passare a lavorare verso una NewHashfutura vulnerabilità in SHA-1 o Hardened-SHA-1.

Quindi la nuova documentazione ora legge:

Git v2.13.0 e versioni successive si sono successivamente spostati su un'implementazione rafforzata di SHA-1 per impostazione predefinita, che non è vulnerabile all'attacco SHAttered.

Pertanto Git è già in effetti migrato a un nuovo hash che non è SHA-1 e non condivide le sue vulnerabilità, la sua nuova funzione hash produce esattamente lo stesso output per tutti gli input conosciuti, ad eccezione di due PDF pubblicati da SHAttered ricercatori e la nuova implementazione (scritta da quei ricercatori) afferma di rilevare futuri attacchi di collisione crittoanalitici.

Indipendentemente da ciò, è considerato prudente superare qualsiasi variante di SHA-1 in un nuovo hash. Non vi è alcuna garanzia che gli attacchi futuri su SHA-1 non saranno pubblicati in futuro e che tali attacchi potrebbero non avere mitigazioni praticabili.

Se SHA-1 e le sue varianti dovessero essere veramente rotti, la funzione hash di Git non potrebbe più essere considerata crittograficamente sicura. Ciò avrebbe un impatto sulla comunicazione dei valori di hash perché non potevamo fidarci che un determinato valore di hash rappresentasse la buona versione conosciuta del contenuto che il relatore intendeva.

Nota: lo stesso documento ora (Q3 2018, Git 2.19) fa esplicito riferimento al "nuovo hash" come SHA-256 : vedi " Perché Git non usa SHA più moderno? ".

Google ora afferma che la collisione SHA-1 è possibile a determinate condizioni preliminari: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Poiché git utilizza SHA-1 per verificare l'integrità dei file, ciò significa che l'integrità dei file in git è compromessa.

IMO, git dovrebbe sicuramente usare un algoritmo di hashing migliore poiché è ora possibile una collisione deliberata.

Una collisione di hashish è così altamente improbabile, che è strabiliante! Gli scienziati di tutto il mondo si stanno sforzando di raggiungerne uno, ma non ce l'hanno ancora fatta. Tuttavia, per alcuni algoritmi come MD5 hanno avuto successo.

Quali sono le probabilità?

SHA-256 ha 2 ^ 256 possibili hash. Sono circa 10 ^ 78 . O per essere più grafico, le probabilità di una collisione sono circa

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 000 000

La possibilità di vincere alla lotteria è di circa 1: 14 milioni . La possibilità di una collisione con SHA-256 è come vincere alla lotteria in 11 giorni consecutivi !

Spiegazione matematica: 14.000.000 ^ 11 ~ 2 ^ 256

Inoltre, l' universo ha circa 10 ^ 80 atomi. Questo è solo 100 volte più di quanto ci siano combinazioni SHA-256.

Riuscita collisione MD5

Anche per MD5 le possibilità sono minime. Tuttavia, i matematici sono riusciti a creare una collisione:

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

ha lo stesso MD5 di

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

Ciò non significa che MD5 sia meno sicuro ora che il suo algoritmo è crackato. È possibile creare collisioni MD5 di proposito, ma la possibilità di una collisione MD5 accidentale è ancora 2 ^ 128, che è ancora molto.

Conclusione

Non devi preoccuparti delle collisioni. Gli algoritmi di hash sono il secondo modo più sicuro per verificare l'uguaglianza dei file. L'unico modo più sicuro è un confronto binario.

Bene, credo che ora sappiamo cosa succederebbe: dovresti aspettarti che il tuo repository venga danneggiato ( fonte ).

Recentemente ho trovato un post dal 29-04-2013 in un gruppo di discussione BSD presso

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

dove il poster afferma:

Ho incontrato una collisione di hash una volta, usando git rebase.

Sfortunatamente, non fornisce alcuna prova per la sua richiesta. Ma forse ti piacerebbe provare a contattarlo e chiedergli di questo presunto incidente.

Ma a un livello più generale, a causa dell'attacco di compleanno la possibilità di una collisione di hash SHA-1 è 1 in pow (2, 80).

Questo suona molto ed è sicuramente molto più del numero totale di versioni di singoli file presenti in tutti i repository Git del mondo messi insieme.

Tuttavia, questo vale solo per le versioni che rimangono effettivamente nella cronologia delle versioni.

Se uno sviluppatore si basa molto sul rebasing, ogni volta che viene eseguito un rebase per un ramo, tutti i commit in tutte le versioni di quel ramo (o parte del ramo rinnovata) ottengono nuovi hash. Lo stesso vale per ogni file modificato con "git filter-branch". Pertanto, "rebase" e "filtro-ramo" potrebbero essere grandi moltiplicatori per il numero di hash generati nel tempo, anche se non tutti vengono effettivamente mantenuti: frequentemente, dopo il rebasing (specialmente allo scopo di "ripulire" un ramo ), il ramo originale viene gettato via.

Ma se la collisione si verifica durante il rebase o il ramo del filtro, può comunque avere effetti negativi.

Un'altra cosa sarebbe stimare il numero totale di entità con hash nei repository git e vedere quanto sono lontani da pow (2, 80).

Diciamo che abbiamo circa 8 miliardi di persone, e tutti eseguiranno git e manterrebbero la versione dei propri contenuti in 100 repository git a persona. Supponiamo inoltre che il repository medio abbia 100 commit e 10 file e che solo uno di questi file cambi per commit.

Per ogni revisione abbiamo almeno un hash per l'oggetto tree e l'oggetto commit stesso. Insieme al file modificato abbiamo 3 hash per revisione e quindi 300 hash per repository.

Per 100 repository di 8 miliardi di persone questo dà pow (2, 47) che è ancora lontano da pow (2, 80).

Tuttavia, ciò non include il presunto effetto moltiplicativo di cui sopra, perché non sono sicuro di come includerlo in questa stima. Forse potrebbe aumentare notevolmente le possibilità di una collisione. Soprattutto se repository molto grandi che hanno una lunga cronologia di commit (come il kernel Linux) vengono ripassati da molte persone per piccoli cambiamenti, che tuttavia creano hash diversi per tutti i commit interessati.