SHA-1 reicht auch heute noch: wie
@tommysenf sagte: der Versions-Hash in Git ist in keiner Weise Sicherheitsrelevant. Er dient dazu, einem Commit, der beliebig groß sein kann, einen eindeutigen und kleinen Identifier zuzuordnen. Dafür ist SHA-1 nach wie vor wunderbar geeignet. Kollisionen kann man zwar provozieren, bei Git versucht das aber niemand; wenn ein Angreiffer Commits in ein Repository pushen kann hat schon eine viel wichtigere Sicherheitsfunktion versagt.
Bei den 160 Bits, die SHA-1 ausgiebt, ist eine Kollision statistisch nach 2^80 Commits zu erwarten. 2^80 = 1,208 * 10^24 = 1.208.000.000.000.000.000.000.000 Das erreicht kein Repository. Zum vergleich:
1. In den Projekten bei meinem aktuellen Arbeitgeber produzieren wir bei Vollzeit-Arbeit im Schnitt 70 Commits pro Monat und Person. Bei dieser Geschwindigkeit müssten wir in einem Team mit 50 Leuten (und das ist für uns lächerlich viel, 5-10 ist realistisch) 2,9 * 10¹⁹ Jahre an dem Projekt arbeiten, bis zwei Commits mit dem selben Hash zu erwarten sind. Der Urknall ist 1,38 * 10⁸ Jahre her.
2.
Das größte Git Repository, was ich auf die schnelle finden konnte, generiert ~ 62.000 commits im Monat, also c.a. 10⁶ commits im Jahr. Selbst dieses Projekt muss zwei Commits mit dem selben Hash erst nach 1,2*10¹⁸ Jahren erwarten.
---
Ein größeres Problem ist die kürzung des Hashes auf 7 Stellen an den meisten Stellen. Mit 7 Stellen gibt es nämlich nur ~ 2,6 * 10⁸ Kombinationen; eine Kollision ist nach 1,3 * 10⁸ commits zu erwarten. Das riesige Git-Repo, welches ich oben nannte, kann damit nach 13 Jahren einen Commit nicht mehr mit den ersten 7 Stellen des Hashes eindeutig identifizieren. Aber 13 Jahre lang 1 Millionen commits / Jahr durchhalten? Unwahrscheinlich.
Fazit: SHA-1 wird seinen Zweck in Git noch seeeeeehr lange mehr als gut genug erfüllen.
