EMZETT.SHA-Typen
Kurz: Übersicht über die verschiedenen Varianten der “Secure Hash Algorithm”-Familie, die sich in Ausgabelänge und internem Aufbau unterscheiden.
Genauer: SHA-1 (160 Bit) gilt seit 2017 als gebrochen und sollte nicht mehr verwendet werden. Die SHA-2-Familie (SHA-256, SHA-224, SHA-384, SHA-512) ist aktuell der De-facto-Standard. SHA-3 basiert auf einem komplett anderen internen Konstruktionsprinzip (Keccak/Sponge-Funktion statt Merkle-Damgård) und dient als Absicherung, falls in SHA-2 künftig Schwächen gefunden werden. Die Wahl der Variante hängt vom Anwendungsfall ab: für die meisten Zwecke reicht SHA-256.
Im Detail
Die drei SHA-Generationen im Überblick, mit dem jeweiligen Sicherheitsstatus:
SHA-1 (1995) - 160 Bit - GEBROCHEN, nicht mehr verwenden
SHA-2 (2001) - 224-512 Bit - aktueller Standard (SHA-256, SHA-384, SHA-512, ...)
SHA-3 (2015) - 224-512 Bit - Backup-Standard, anderer interner Aufbau (Keccak)
Warum überhaupt eine dritte Generation, wenn SHA-2 noch als sicher gilt? Die NSA/NIST wollte für den Fall vorsorgen, dass in Zukunft ein grundlegender Angriff auf die Merkle-Damgård-Konstruktion gefunden wird, auf der sowohl SHA-1 als auch SHA-2 aufbauen (genau diese Konstruktion machte SHA-1 letztlich angreifbar) — SHA-3 nutzt mit der “Sponge”-Konstruktion ein komplett anderes mathematisches Prinzip, sodass ein Angriff auf SHA-2 nicht automatisch auch SHA-3 betrifft. SHA-3 ist deshalb eine bewusste Diversifizierung, kein direkter Nachfolger, der SHA-2 ablösen soll.
In der Praxis begegnet man fast ausschließlich SHA-2-Varianten (v. a. SHA-256): TLS-Zertifikate, Git-Commits, Paketmanager-Signaturen und die meisten Passwort-Hashing-Bibliotheken bauen darauf auf. SHA-3 wird bisher seltener aktiv eingesetzt, ist aber z. B. Grundlage einiger neuerer Standards. Bei der Wahl gilt als Faustregel: SHA-256 für die meisten Zwecke, SHA-512 wenn Performance auf 64-Bit-Systemen wichtiger ist als eine minimal kleinere Ausgabe, SHA-3 nur wenn ein Standard es explizit verlangt.
Der Fall SHA-1 als Warnung
Der Niedergang von SHA-1 zeigt exemplarisch, wie kryptografische Algorithmen über Zeit unsicher werden können, ohne dass sich am Algorithmus selbst etwas ändert — nur die verfügbare Rechenleistung und die mathematischen Angriffstechniken entwickeln sich weiter. Bereits ab 2005 zeigten theoretische Arbeiten Schwächen in SHA-1 auf, die eine Kollisionssuche schneller als im ursprünglich gedachten Sicherheitsniveau erlaubten; praktisch demonstriert wurde die erste tatsächliche Kollision aber erst 2017 mit “SHAttered”. Zwischen der ersten theoretischen Warnung und der breiten Abschaltung von SHA-1 in Browsern und Zertifizierungsstellen lagen mehr als zehn Jahre — ein Beispiel dafür, wie träge sich große, verteilte Systeme (Millionen Webserver, Millionen installierte Browser) auf einen notwendigen kryptografischen Wechsel umstellen, selbst wenn die Notwendigkeit längst bekannt ist.
Wie eine Migration in der Praxis abläuft
Der Umstieg von einem unsicher gewordenen Hash-Algorithmus auf einen neuen ist selten trivial, weil er Rückwärtskompatibilität berücksichtigen muss: Git etwa unterstützt seit einigen Versionen experimentell SHA-256 als Alternative zum traditionellen SHA-1 für Commit-Hashes, muss dabei aber sicherstellen, dass bestehende Repositories und ihre komplette Historie weiterhin funktionieren. Zertifizierungsstellen mussten Übergangsfristen einhalten, in denen sowohl SHA-1- als auch SHA-256-signierte Zertifikate parallel unterstützt wurden, bevor SHA-1-Zertifikate schließlich vollständig als unsicher markiert und von Browsern abgelehnt wurden.
Wie man die richtige Variante für ein eigenes Projekt auswählt
Für ein eigenes Projekt lässt sich die Wahl auf eine kurze Entscheidungskette reduzieren: SHA-1 kommt kategorisch nicht mehr infrage, egal wie gering der scheinbare Anwendungsfall wirkt. Für allgemeine Integritätsprüfung, Zertifikate und die meisten Signaturverfahren ist SHA-256 der pragmatische Standard, der von praktisch jeder Bibliothek und jedem System unterstützt wird. Für Passwörter sollte ohnehin kein reiner SHA-Algorithmus direkt verwendet werden, sondern ein dediziertes, absichtlich langsames Verfahren wie bcrypt oder Argon2. SHA-3 oder SHA-512 werden meist nur gewählt, wenn ein konkreter Standard oder eine konkrete Plattform (z. B. bestimmte Blockchain-Protokolle) sie explizit vorschreibt — ansonsten bringt der Wechsel keinen praktischen Zusatznutzen gegenüber dem etablierten SHA-256.