SHA-1 vs. SHA-256: SHA-1 ist tot, doch Git nutzt es weiter

Kurz gesagt. SHA-1 ist kryptografisch gebrochen – eine praktische Kollision wurde 2017 von Google demonstriert, und Chosen-Prefix-Angriffe wurden 2020 erschwinglich – nutzen Sie daher für jede neue Sicherheitsanwendung SHA-256. Git verwendet noch SHA-1 für Objekt-Hashes, migriert aber; nicht sicherheitsrelevantes Fingerprinting (Caches, Deduplizierung) ist nicht betroffen.

SHA-1 (160-Bit-Ausgabe, 1995) und die SHA-2-Familie (256/384/512-Bit-Ausgabe, 2001) sind beide von NIST veröffentlichte kryptografische Hashfunktionen. SHA-1 war durch die 2000er der dominierende Integritäts-Hash. Es ist heute überall dort veraltet, wo Sicherheit zählt – aber noch nicht überall.

Das Wichtigste

Wie SHA-1 brach

Eine kryptografische Hashfunktion sollte es rechnerisch unmöglich machen, zwei Eingaben zu finden, die denselben Hash erzeugen. SHA-1s 160-Bit-Ausgabe bot auf dem Papier eine Kollisionsresistenz von 2⁸⁰ – weit jenseits der Brute-Force-Budgets zum Entwurfszeitpunkt 1995.

Drei Meilensteine höhlten das aus:

1. 2005: Wang, Yin und Yu veröffentlichten einen theoretischen Angriff, der die Kollisionssuche auf ~2⁶⁹ Operationen reduzierte – damals noch nicht machbar, aber ein klarer Warnschuss.
2. 2017: Googles SHAttered-Projekt demonstrierte die erste praktische SHA-1-Kollision: zwei PDFs mit demselben SHA-1-Hash. Kosten: ~110.000 $ an GPU-Rechenleistung und 9 Trillionen SHA-1-Auswertungen.
3. 2020: Leurent und Peyrin veröffentlichten einen Chosen-Prefix-Kollisionsangriff – nimm zwei beliebige Dateiköpfe, hänge sorgfältig konstruierte Bytes an und erzeuge kollidierende Dateien. Kosten: ~45.000 $ an Cloud-Rechenleistung. Das ist die Art von Angriff, die gefälschte Zertifikate und gefälschte Signaturen im realen Einsatz ermöglicht.

Nach 2020 ist SHA-1 für jeden Sicherheitszweck ungeeignet, bei dem Fälschung eine Rolle spielt.

Wo SHA-1 noch akzeptabel ist

Nicht-adversariales Fingerprinting – wo es keinen Anreiz für einen Angreifer gibt, Kollisionen zu fälschen – ist mit SHA-1 weiterhin in Ordnung:

• Git-Commit- und Tree-Objekt-Hashes. Ein Angreifer, der eine Kollision fälscht, müsste konstruierte Commits einschleusen und in gängige Spiegel übernehmen lassen. Git führt zudem bei jeder Operation eine SHA-1-Erkennung bekannter Angriffsmuster (die SHAttered-Erkennung) durch und macht das Einschleusen sichtbar.
• Inhaltsadressierter Speicher, bei dem Sie alle Eingaben kontrollieren (Build-Caches, CDN-Deduplizierung).

Selbst in diesen Fällen ist SHA-256 der richtige Standard für neue Systeme. Die Geschwindigkeitslücke (SHA-256 ist auf den meisten modernen CPUs ~40 % langsamer als SHA-1) ist für fast jede Last irrelevant.

Wo SHA-256 zwingend ist

• TLS-Zertifikatssignaturen. Browser akzeptieren SHA-1 seit 2017 nicht mehr.
• JWT-Signaturen (HS256, RS256, ES256). Die 256 steht für SHA-256.
• Code-Signing. Microsoft und Apple akzeptierten SHA-1-Signaturen ab etwa 2016–2017 nicht mehr.
• Überall, wo Kollisionsangriffe Fälschung ermöglichen würden. Dokumentsignaturen, Kryptowährungen, Identitätsnachweise.

Die Git-Migration

Git migriert seit 2018 zu SHA-256. Die Migration ist technisch unkompliziert, dauert aber, weil jeder Git-Server, jedes CI/CD-System und jeder Abhängigkeitsmanager beide unterstützen muss. Stand 2026:

• SHA-256-Repositorys funktionieren auf modernem Git durchgängig.
• GitHub unterstützt SHA-256-Repos, voreingestellt ist aber SHA-1 für neue Repos.
• GitLab und Bitbucket: teilweise Unterstützung, je nach Version unterschiedlich.
• Die meisten CI-Integrationen funktionieren mit beiden.

Das Standardverhalten der Git-CLI ist weiterhin SHA-1. Um ein SHA-256-Repo zu erstellen: git init --object-format=sha256. Sobald die Migration abgeschlossen ist – wahrscheinlich im Zeitraum 2027–2028 – wird die Voreinstellung umkippen.

Die pragmatische Regel

• Für neue Systeme: SHA-256. Immer. Die Geschwindigkeitslücke spielt keine Rolle.
• Für bestehende SHA-1-Systeme: migrieren, wenn machbar, aber keine Panik – die Bedrohung ist real, aber spezifisch.
• Speziell für Git: SHA-1 ist vorerst in Ordnung. Achten Sie darauf, wann SHA-256 zur Voreinstellung wird.
• Für TLS, Code-Signing, JWT, Krypto: SHA-256 war ohnehin schon die einzig akzeptable Wahl.

Berechnen Sie beide Hashes mit unserem Hash-Generator.

Zahlenfakten

• Hex-Länge: SHA-1 = 40 Zeichen (160 Bit); SHA-256 = 64 Zeichen (256 Bit); base64url = 27 Zeichen gegenüber 43 Zeichen ohne Padding.
• Geburtstags-gebundene Kollisionsresistenz: SHA-1 ~2⁸⁰ generisch, nach dem SHAttered-Angriff 2017 auf ~2⁶¹ gefallen; SHA-256 bleibt bei ~2¹²⁸.
• SHAttered-Kosten (2017): 9.223.372.036.854.775.808 SHA-1-Auswertungen, ~110.000 $ an GPU-Cloud-Zeit, äquivalent zu 6.500 CPU-Jahren.
• Chosen-Prefix-Angriff (Leurent & Peyrin, 2020): ~45.000 $ auf AWS – erschwinglich für mittelgroße kriminelle Operationen.
• Durchsatz mit Intel SHA-NI (Ice Lake / Zen 3+): SHA-1 ~2,1 GB/s/Kern; SHA-256 ~1,9 GB/s/Kern – Hardwarebeschleunigung verkleinert die Lücke auf ~10 %, nicht 40 %.
• Ohne Hardwarebeschleunigung: SHA-1 ~700 MB/s gegenüber SHA-256 ~400 MB/s – die altbekannte ~40-%-Lücke, die oft zitiert wird.
• Blockgröße: beide nutzen 512-Bit-Blöcke; SHA-1 erzeugt einen 160-Bit-Zustand, SHA-256 einen 256-Bit-Zustand.
• Browser 2017: Chrome 56, Firefox 51, Edge – alle akzeptierten am 24. Januar 2017 keine SHA-1-TLS-Zertifikate mehr.

Entscheidungsmatrix

Quellen

• NIST FIPS 180-4 – Secure Hash Standard – csrc.nist.gov/pubs/fips/180-4.
• Stevens, M. et al. – The first collision for full SHA-1, CRYPTO 2017 (SHAttered) – shattered.io.
• Leurent, G. & Peyrin, T. – SHA-1 is a Shambles, USENIX Security 2020 – sha-mbles.github.io.