SHA-1 vs. SHA-256 vs. SHA-512: Den richtigen Hash-Algorithmus wählen 2026

Öffne ein TLS-Zertifikat, eine Git-Objektdatenbank, einen Bitcoin-Block-Header, einen Linux-Paketmanager oder ein Docker-Image-Manifest — in jedem dieser Systeme steckt ein SHA-Hash. Aber nicht derselbe. SHA-1, SHA-256, SHA-384, SHA-512, SHA-3: Die Familie umspannt drei Jahrzehnte, zwei Designlinien und einen entscheidenden Kollisionsangriff, der das älteste Mitglied im produktiven Einsatz gebrochen hat.

Dieser Leitfaden kartiert die gesamte Familie, damit du den richtigen Algorithmus für deinen Anwendungsfall wählst — ohne lange zweifeln zu müssen.

Entscheidungsbaum auf einen Blick

Bevor wir ins Detail gehen, ist hier die Zusammenfassung, die die meisten Entwicklerinnen und Entwickler tatsächlich brauchen:

Dein Szenario	Beste Wahl	Begründung
TLS/HTTPS-Zertifikat	SHA-256 (Minimum), SHA-384 bei hoher Sicherheit	Vorgeschrieben durch CA/Browser Forum Baseline Requirements
JWT-Signierung (HMAC oder RSA)	SHA-256 (HS256/RS256)	Universale Unterstützung; SHA-384/512 für Compliance-Anforderungen
Software-Integritätsprüfsumme	SHA-256	Industriestandard; weit verbreitet
Archivarische oder langlebige Integrität	SHA-512	Größere Ausgabe, sichere Reserve für kommende Jahrzehnte
Content Addressing (IPFS, OCI)	SHA-256	De-facto-Standard für inhaltsadressierbare Speichersysteme
Git (bestehende Repos lesen/schreiben)	SHA-1 für bestehende; SHA-256 für neue via `--object-format=sha256`	Git ist mitten in der Migration; SHA-1 dominiert noch
Interoperabilität mit Ethereum	Keccak-256 (nicht NIST SHA-3)	Ethereum nutzt die Keccak-Variante vor der Standardisierung
Defense-in-depth oder klassifizierte Systeme	SHA-384 oder SHA-512	NSA Suite B; kombiniert mit AES-256-GCM
Neuer Code, keine Legacy-Abhängigkeiten	SHA-3 (SHA3-256)	Andere Designlinie; keine Length-Extension-Schwachstelle
Passwortspeicherung	Keiner der obigen	Verwende bcrypt, Argon2id oder scrypt — SHA ist zu schnell

Die SHA-Familie im Überblick

Algorithmus	Standard	Ausgabe-Bits	Hex-Zeichen	Jahr	NIST-Status	Hauptverwendung heute
SHA-1	FIPS 180-4	160	40	1995	Deprecated (2011), für digitale Signaturen zurückgezogen	Git Legacy, Fingerprints
SHA-256	FIPS 180-4	256	64	2001	Aktuell	TLS, JWT, Bitcoin, Prüfsummen
SHA-384	FIPS 180-4	384	96	2001	Aktuell	Suite B, hochsicherheits-TLS
SHA-512	FIPS 180-4	512	128	2001	Aktuell	Archivierung, LUKS, HMAC-SHA-512
SHA-3 (beliebige Variante)	FIPS 202	224/256/384/512	variabel	2015	Aktuell	Alternative Designlinie, Hardwarebeschleunigung

SHA-1 und SHA-2 (die 256/384/512-Gruppe) teilen eine Merkle-Damgård-Konstruktion. SHA-3 verwendet eine Schwammkonstruktion (Sponge Construction) — eine Unterscheidung, die bedeutsamer ist, als sie auf den ersten Blick wirkt; dazu mehr weiter unten.

SHA-1: Gebrochen, aber nicht tot

SHA-1 war das Arbeitspferd der 2000er-Jahre. SSL-Zertifikate, S/MIME-E-Mail, PGP-Fingerprints und Git konvergierten alle darauf. Dann veröffentlichten Google und CWI Amsterdam im Februar 2017 SHAttered: einen Chosen-Prefix-Kollisionsangriff, der zwei unterschiedliche PDF-Dateien mit identischem SHA-1-Hash produzierte. Der Angriff erforderte rund 6,5 × 10^19 SHA-1-Berechnungen — teuer im Jahr 2017, heute mit Cloud-Compute erschwinglich.

NIST hatte SHA-1 für digitale Signaturen bereits 2011 als veraltet eingestuft (NIST Special Publication 800-131A). Die SHAttered-Demonstration beschleunigte die Bereinigung: Browser vertrauten SHA-1-TLS-Zertifikaten ab 2017 nicht mehr, und das CA/Browser Forum machte SHA-256 für neue Ausstellungen verpflichtend.

Wo SHA-1 noch verwendet wird:

Git-Objektdatenbank: Git wurde rund um SHA-1 als schnellen Content-Hash konzipiert, nicht als Sicherheitsprimitiv. Das Repository-Format hardcodet 40-Hex-Objekt-IDs. Ein Migrationspfad zu SHA-256 (git init --object-format=sha256) existiert, wird aber langsam adoptiert, da jede gehostete Plattform, jedes CI-Tool und jeder bestehende Clone synchron migrieren müsste.
Fingerprints in Legacy-Systemen: Alte SSH-Host-Key-Fingerprints, PGP-Schlüssel-Fingerprints und Zertifikats-Seriennummernschemas legen noch SHA-1-Werte offen. Diese sind informativ, nicht sicherheitskritisch in den meisten Kontexten.

Was zu tun ist: Verwende SHA-1 nicht für irgendetwas Neues. Bei Git ist das Kollisionsrisiko für typische Softwareentwicklungs-Workflows gering (ein Angreifer müsste beide Dateien der Kollision kontrollieren), aber neue Projekte mit --object-format=sha256 sind die richtige langfristige Richtung.

Erzeuge einen SHA-1-Hash im Browser: SHA-1 Generator.

SHA-256: Das Arbeitspferd

SHA-256 ist der Algorithmus, auf dem das Internet 2026 läuft. Jedes TLS-Zertifikat, das von einer öffentlichen CA ausgestellt wird, verwendet SHA-256 als Signatur-Hash. Jedes JWT, das mit HS256, RS256 oder ES256 signiert wird, nutzt SHA-256 intern. Bitcoins Proof-of-Work ist Double-SHA-256. Docker-Content-Hashing ist SHA-256. npm-Paketintegrität verwendet SHA-256.

Die Gründe sind praktisch:

Sicherheitsmarge: 256 Bits Ausgabe bedeuten 2^128 Operationen für einen Brute-Force-Preimage-Angriff — jenseits jeder vorstellbaren Hardware auf absehbare Zeit. Das tatsächliche Sicherheitsniveau ist durch Birthday-Bound-Kollisionsangriffe leicht niedriger (2^128 Operationen), immer noch unangreifbar.
Hardwarebeschleunigung: SHA-256 ist in Silizium implementiert auf jedem Intel Goldmont+ CPU (SHA-NI-Erweiterung), jedem Apple-Silicon-Chip, jedem ARMv8-Prozessor sowie dedizierten ASICs in Netzwerkgeräten und Speichercontrollern. Wenn der Hardware-Pfad gewählt wird, übersteigt der SHA-256-Durchsatz viele scheinbar schnellere Software-Alternativen.
Allgegenwärtige Bibliotheksunterstützung: Jede TLS-Bibliothek, jede JWT-Bibliothek, jede Standardbibliothek einer Programmiersprache implementiert SHA-256. Du wirst auf keine Kompatibilitätshürde stoßen.

Für Content Addressing, Integritätsprüfung und die meisten Signierungsworkflows ist SHA-256 der richtige Standard, sofern kein spezifischer Standard etwas anderes vorschreibt.

Erzeuge einen SHA-256-Hash im Browser: SHA-256 Generator.

SHA-384: Die TLS-Spezialität

SHA-384 ist SHA-512, auf 384 Bits gekürzt. Er wurde geschaffen, um ein 192-Bit-Sicherheitsniveau zu bieten (die Hälfte der Ausgabegröße ist die Kollisionsresistenz-Untergrenze) und in NSA Suite B Cryptography neben AES-256-GCM und P-384-Elliptische-Kurven-Schlüsseln aufgenommen.

Zwei Eigenschaften machen SHA-384 speziell attraktiv für TLS:

Length-Extension-Immunität bei dieser Ausgabelänge: SHA-256 und SHA-512 sind anfällig für Length-Extension-Angriffe — ein Angreifer, der H(secret || message) kennt, kann H(secret || message || extension) berechnen, ohne das Geheimnis zu kennen. SHA-384 und SHA-512/256 werden aus dem vollständigen internen Zustand gekürzt, sodass Length Extension nicht anwendbar ist. Wenn du rohe SHA-Hashes als MACs verwendest (statt HMAC), ist SHA-384 sicherer.
Suite-B-Compliance: Organisationen, die NSA/CNSA-Anforderungen (Commercial National Security Algorithm) erfüllen müssen, müssen SHA-384 oder SHA-512 neben RSA-3072+, ECDH P-384 und AES-256 einsetzen. Wenn dein Kunde eine US-Bundesbehörde oder ein Auftragnehmer unter FIPS 140-3-Anforderungen ist, kann SHA-384 vorgeschrieben sein.

SHA-384 ist für die meisten Anwendungsfälle nicht wesentlich sicherer als SHA-256 — der praktische Unterschied zwischen 128-Bit- und 192-Bit-Kollisionsresistenz ist bei aktuellen Rechenniveaus theoretisch. Wähle es, wenn Compliance oder die Suite-B-Paarung es erfordert, nicht für den allgemeinen Einsatz.

Erzeuge einen SHA-384-Hash im Browser: SHA-384 Generator.

SHA-512: Wenn du mehr Bits brauchst

SHA-512 erzeugt einen 512-Bit-(128-Hex-Zeichen-)Digest. Auf 64-Bit-Hardware ist er oft schneller als SHA-256, weil der Algorithmus auf 64-Bit-Wörtern operiert statt auf 32-Bit-Wörtern — SHA-256s interner Schedule verwendet 32-Bit-Arithmetik, während SHA-512 64-Bit-Arithmetik nutzt, die auf modernen CPUs effizienter abgebildet wird.

Benchmarks auf 64-Bit-Hardware (indikativ; Browser Web Crypto API):

Algorithmus	Ungefährer Durchsatz
SHA-1	~600 MB/s
SHA-256	~500 MB/s
SHA-384	~700 MB/s
SHA-512	~700 MB/s
SHA-3-256	~300 MB/s

Hinweis: SHA-384 und SHA-512 teilen dieselbe interne Kompressionsfunktion und laufen daher mit gleicher Geschwindigkeit. SHA-256 ist auf 64-Bit langsamer, weil seine 32-Bit-Wortgröße mehr Iterationen zur Verarbeitung jedes 512-Bit-Nachrichtenblocks erfordert. Auf 32-Bit- oder eingeschränkter Hardware ist SHA-256 schneller.

SHA-512 eignet sich besonders für:

Archivarische Integrität: Prüfsummen, die Jahrzehnte überdauern sollen, profitieren von der größeren Ausgabemarge.
Festplattenverschlüsselung im Vollzugriff: Linux LUKS verwendet SHA-512 als Standard-KDF-Hash für die Schlüsselableitung (als Komponente von PBKDF2, nicht als eigenständiger Hash).
HMAC-SHA-512: Verwendet in einigen JWT-Signierungsschemas (HS512) und API-Authentifizierung, bei der größere MACs bevorzugt werden.
Generierung großer Mengen pseudozufälliger Daten: Anwendungen, die einen Seed hashen und viele Ausgabe-Bits benötigen, können SHA-512 verwenden, um die Anzahl der Hash-Aufrufe zu reduzieren.

Erzeuge einen SHA-512-Hash im Browser: SHA-512 Generator.

SHA-3: Eine andere Designphilosophie

SHA-3 ist nicht SHA-2 mit größerer Ausgabe. Es ist ein grundlegend anderer Algorithmus, basierend auf einer Schwammkonstruktion namens Keccak, entworfen von Guido Bertoni, Joan Daemen, Michaël Peeters und Gilles Van Assche. NIST wählte ihn als Gewinner eines siebenjährigen öffentlichen Wettbewerbs (2007–2012) aus, der eine Hash-Familie hervorbringen sollte, die als Backup dienen könnte, falls Schwächen in SHA-2s Merkle-Damgård-Konstruktion gefunden würden.

Die Schwammkonstruktion funktioniert anders als Merkle-Damgård:

Die Eingabe wird aufgefüllt und in Blöcke aufgeteilt.
Jeder Block wird per XOR in den ersten Teil eines großen internen Zustands (die „Rate”) eingespeist, dann wird der gesamte Zustand mit der Keccak-f-Permutation permutiert.
Nachdem alle Eingaben absorbiert wurden, wird die Ausgabe aus dem Rate-Anteil des Zustands „herausgequetscht”.

Da die Ausgabe nur aus einem Teil des Zustands extrahiert wird und der Kapazitätsanteil nie direkt exponiert ist, sind Schwammkonstruktionen ohne Kürzung inhärent immun gegen Length-Extension-Angriffe.

SHA-3-Standardvarianten (FIPS 202):

Variante	Ausgabe-Bits	Sicherheitsniveau
SHA3-224	224	112-Bit
SHA3-256	256	128-Bit
SHA3-384	384	192-Bit
SHA3-512	512	256-Bit
SHAKE128	variabel	128-Bit
SHAKE256	variabel	256-Bit

SHA-3 vs. SHA-2 in der Praxis:

SHA-3 ist in Protokollen, die vor 2015 entworfen wurden, noch nicht weit verbreitet — TLS, JWT und der Großteil der Internetinfrastruktur verwenden weiterhin SHA-2. SHA-3 taucht in Post-Quanten-Signaturverfahren auf (CRYSTALS-Dilithium, SPHINCS+ verwenden SHA-3 intern), in neuen Protokolldesigns, die ein Backup einer anderen Designlinie wünschen, und in Hardware, wo die Keccak-Permutation gut beschleunigt werden kann. In reiner Software ist SHA-3 auf x86 etwa 40 % langsamer als SHA-256.

Erzeuge einen SHA-3-Hash im Browser: SHA-3 Generator.

Der Ethereum-Keccak-256-Unterschied

Ein wichtiger Fallstrick: Ethereum verwendet nicht NIST SHA-3. Ethereum wurde während des laufenden Keccak-Wettbewerbs entworfen, vor der Finalisierung von FIPS 202 durch NIST. Die Ethereum Virtual Machine verwendet die originale Keccak-256-Einreichung, die ein anderes Padding als der finalisierte NIST SHA-3-Standard verwendet.

Konkret:

NIST SHA3-256 hängt vor dem letzten Block 0x06-Padding an.
Originales Keccak-256 (wie von Ethereum verwendet) hängt 0x01-Padding an.

Dieselbe Eingabe produziert unterschiedliche Hashes. Der Aufruf von NIST SHA3-256 und der Aufruf von Ethereums keccak256 sind nicht austauschbar. Die meisten Sprachen bieten beide: In Python ist hashlib.sha3_256() NIST SHA-3; für Keccak-256 wie es Ethereum verwendet, benötigst du eine Bibliothek wie pysha3 (die keccak_256 implementiert). In JavaScript legt die Bibliothek js-sha3 beide offen. Der SHA-3 Generator implementiert NIST SHA3-256 — wenn du Ethereum-Keccak-256-Hashes benötigst, verwende ein Ethereum-spezifisches Tool.

Performance-Benchmarks

Die folgenden Zahlen sind indikativ für die Browser Web Crypto API auf einem modernen x86-64-Laptop. Der tatsächliche Durchsatz variiert je nach Hardware, Nachrichtengröße und ob die Plattform einen Hardware-Beschleunigungspfad verwendet.

Algorithmus	Streaming-Durchsatz (64-Bit)
SHA-1	~600 MB/s
SHA-256	~500 MB/s
SHA-384	~700 MB/s
SHA-512	~700 MB/s
SHA-3-256	~300 MB/s

Für kleine Nachrichten (API-Tokens, Prüfsummen unter wenigen KB) führen alle Algorithmen in unter 2 µs aus — der Unterschied ist unsichtbar. Für große Daten (Tarballs, Disk-Images) schlagen SHA-384/512 SHA-256 auf 64-Bit-Systemen, weil sie auf 64-Bit-Wörtern operieren. SHA-3 ist in reiner Software langsamer; bevorzuge SHA-2 in durchsatzkritischem Code, sofern keine Hardware-Keccak-Beschleunigung verfügbar ist. SHA-1-Durchsatz ist niemals ein Grund, es zu verwenden.

Typische Fallstricke

Encoding-Diskrepanzen

SHA operiert auf Bytes. Wenn du den String "hello" in einem Browser hashst, wo JavaScript ihn als UTF-16 statt UTF-8 kodiert, erhältst du einen anderen Digest als ein Python-Skript, das str.encode("utf-8") verwendet. Normalisiere immer zu UTF-8, bevor du Text hashst.

Ein konsistentes Muster:

const encoder = new TextEncoder(); // UTF-8
const data = encoder.encode(inputString);
const hashBuffer = await crypto.subtle.digest("SHA-256", data);

Fehlendes Salting bei MACs

Die Verwendung eines rohen SHA-Hashes als Message Authentication Code (H(secret || message)) ist anfällig für Length-Extension-Angriffe auf SHA-256 und SHA-512. Verwende stattdessen HMAC (RFC 2104): HMAC-SHA256(key, message). HMAC umschließt den Hash mit einem inneren und äußeren verschlüsselten Pad, der Extension-Angriffe verhindert.

Length-Extension auf SHA-256

Wenn du eine API-Signatur als SHA256(secret + payload) konstruierst, kann ein Angreifer, der den resultierenden Hash kennt, SHA256(secret + payload + attacker_extension) berechnen, ohne das Geheimnis zu kennen. Lösung: Verwende HMAC, oder SHA-3 (konstruktionsbedingt immun), oder SHA-384/SHA-512/256 (immun durch Kürzung).

Keccak-256 mit NIST SHA-3 verwechseln

Wie oben beschrieben: Ethereum verwendet Keccak-256 mit 0x01-Padding; NIST SHA3-256 verwendet 0x06-Padding. Sie produzieren unterschiedliche Ausgaben bei derselben Eingabe. Überprüfe, welche Variante deine Bibliothek implementiert, bevor du mit Ethereum-Contracts oder Solidity-ABI-Encoding integrierst.

SHA für Passwörter verwenden

SHA-Algorithmen sind darauf ausgelegt, schnell zu sein. Das ist genau die falsche Eigenschaft für die Passwortspeicherung: Ein GPU-Cluster kann Milliarden von SHA-256-Hashes pro Sekunde berechnen, was einen Wörterbuchangriff auf eine SHA-gehashte Passwortdatenbank praktisch macht. Für Passwörter verwende eine speicherintensive Schlüsselableitungsfunktion: Argon2id (empfohlen), bcrypt oder scrypt. Speichere Passwörter niemals als rohe SHA-Hashes, auch nicht gesalzt.

Häufig gestellte Fragen

Was ist der Unterschied zwischen SHA-1 und SHA-256?

SHA-1 und SHA-256 sind beide Merkle-Damgård-Hashfunktionen, standardisiert in FIPS 180-4, aber SHA-256 produziert einen 256-Bit-Digest gegenüber SHA-1s 160-Bit-Digest. Wichtiger ist, dass SHA-1 gebrochen wurde: Ein realer Kollisionsangriff (SHAttered, 2017) demonstrierte zwei unterschiedliche PDF-Dateien mit demselben SHA-1-Hash. SHA-256 hat keine bekannten Kollisionsangriffe und bietet ein 128-Bit-Kollisionsresistenz-Niveau. Verwende SHA-256 für alles, das Integritätsgarantien erfordert; verwende SHA-1 nicht für neue Arbeiten.

Ist SHA-512 schneller als SHA-256?

Auf 64-Bit-Hardware ja, oft um 30–40 % bei großen Eingaben. SHA-512 verwendet 64-Bit-Wort-Arithmetik, die moderne CPUs nativ verarbeiten. SHA-256 verwendet 32-Bit-Wort-Arithmetik und erfordert doppelt so viele Operationen pro Nachrichtenblock auf derselben Hardware. Auf 32-Bit-Plattformen oder eingeschränkten Mikrocontrollern ist SHA-256 schneller. Für kurze Nachrichten (unter wenigen KB) ist der Unterschied nicht wahrnehmbar.

Sollte ich von SHA-1 zu SHA-256 migrieren?

Für digitale Signaturen, TLS-Zertifikate und Code-Signierung: Ja, unbedingt — SHA-1 ist veraltet und aktiv gebrochen. Für Git-Repositories: Der Migrationspfad existiert (git init --object-format=sha256), aber die Adoption ist wegen Ökosystem-Koordinationsanforderungen langsam; das Kollisionsrisiko für typische Repository-Nutzung ist gering. Für informative Fingerprints (SSH-Host-Key-Anzeige): Die Sicherheitsexposition ist minimal, aber die Migration zu SHA-256 ist gute Hygiene.

Kann SHA-256 umgekehrt werden?

Nein. SHA-256 ist konstruktionsbedingt eine Einwegfunktion. Aus einem Hash lässt sich die ursprüngliche Eingabe mathematisch nicht zurückgewinnen. Was Angreifer tun können, ist einen Wörterbuch- oder Brute-Force-Angriff durchführen: Millionen von Kandidateneingaben hashen und vergleichen. Für Eingaben mit geringer Entropie (kurze Zeichenketten, gängige Passwörter, sequenzielle Zahlen) machen vorberechnete Rainbow Tables dies praktisch. Für Eingaben mit hoher Entropie (zufällige UUIDs, große Dateien) ist eine Umkehrung rechnerisch nicht durchführbar. Deshalb ist SHA allein für Passwörter ungeeignet — du brauchst eine langsame, gesalzte KDF.

Wann sollte ich SHA-3 statt SHA-2 verwenden?

SHA-3 ist angemessen, wenn: (a) du einen Hash aus einer anderen Designlinie als Absicherung gegen zukünftige SHA-2-Schwächen willst; (b) dein Protokoll Length-Extension-Immunität ohne HMAC erfordert; (c) du Post-Quanten-Signaturverfahren implementierst, die intern SHA-3 spezifizieren; oder (d) du Hardware-Beschleunigung für Keccak hast und Durchsatz benötigst. Für die meisten alltäglichen Anwendungsfälle (TLS, JWT, Prüfsummen) hat SHA-256 breitere Ökosystemunterstützung und ist die pragmatische Standardwahl. SHA-3 ist bei gleichen Ausgabelängen nicht sicherer als SHA-2 — es ist eine andere Wette auf langfristige Sicherheit.

Warum verwendet Ethereum Keccak-256 statt NIST SHA-3?

Ethereum wurde 2013–2014 entworfen, bevor NIST FIPS 202 (August 2015) veröffentlichte und den SHA-3-Standard finalisierte. Damals galt die Keccak-Einreichung als wahrscheinlicher Gewinner, und Ethereums Autoren verwendeten sie direkt. Als NIST den Standard finalisierte, änderten sie das Domain-Separation-Padding von 0x01 (Keccak original) auf 0x06, was bei gleicher Eingabe unterschiedliche Ausgaben produziert. Ethereum war bereits mit dem originalen Keccak-Padding deployt und konnte es nicht ändern. Daher sind „Ethereum keccak256” und „NIST SHA3-256” unterschiedliche Algorithmen, obwohl sie dieselbe zugrunde liegende Keccak-f-Permutation teilen.

Probiere die Tools aus: SHA-1 · SHA-256 · SHA-384 · SHA-512 · SHA-3 — alle laufen im Browser, keine Daten verlassen deinen Rechner.

SHA-1 vs SHA-256 vs SHA-512: Hash-Algorithmus 2026