SHA-256 vs. SHA-3 vergleicht das Arbeitspferd der SHA-2-Familie mit dem auf Keccak basierenden Standard, den NIST 2015 veröffentlicht hat. Keines der beiden Verfahren ist gebrochen oder steht auch nur kurz davor, und beide bieten bei 256 Bit Ausgabelänge dieselbe nominelle Sicherheit. Der Unterschied liegt im inneren Aufbau, der sich auf Length Extension, Geschwindigkeit und die Verwendung in neueren Algorithmen auswirkt.
Auf einen Blick
| SHA-256 | SHA3-256 | |
|---|---|---|
| Standard | FIPS 180-4 (Familie von 2001, Revision von 2015) | FIPS 202 (2015) |
| Konstruktion | Merkle-Damgård, 64 Runden einer 32-Bit-Kompressionsfunktion | Sponge über die 1600-Bit-Permutation Keccak-f, 24 Runden |
| Ausgabe | 256 Bit | 256 Bit |
| Resistenz gegen Kollisionen / Urbilder | 128 / 256 Bit | 128 / 256 Bit |
| Length Extension | Ja, hash(secret ‖ m) ist kein MAC | Nein |
| Verwandte Funktionen mit erweiterbarer Ausgabe | Keine | SHAKE128, SHAKE256 |
| Durchsatz, Eingaben von 16 KiB, OpenSSL 3.6.5 | etwa 2,85 GB/s | etwa 1,01 GB/s |
| Durchsatz, Eingaben von 16 Byte | etwa 0,17 GB/s | etwa 0,07 GB/s |
| CPU-Befehle | SHA-Erweiterungen von Intel und AMD, ARMv8 SHA2 | SHA3-Befehle von ARMv8.2 (EOR3, RAX1, XAR, BCAX) |
| Vorgeschrieben von | TLS, X.509, JOSE S256 und RS256 usw., Bitcoin, Git (SHA-256-Repositorys) | ML-KEM, ML-DSA (SHAKE und SHA3), SHAKE-Parametersätze von SLH-DSA, Ed448 (SHAKE256) |
| Einfluss von Quantencomputern | Grover: Aufwand für Urbilder sinkt höchstens auf die Quadratwurzel; weiterhin zugelassen | Ebenso |
Durchsatz gemessen mit openssl speed -evp auf einem Kern eines Apple M4 Max, der beide Familien in Hardware unterstützt.
Aufbau
SHA-256 verarbeitet die Nachricht in 64-Byte-Blöcken und gibt jeden davon zusammen mit dem vorherigen 256-Bit-Zustand in eine Kompressionsfunktion; der letzte Zustand ist der Digest. Weil der Digest der gesamte innere Zustand ist, kann jeder, der SHA-256(x) und die Länge von x kennt, weiterhashen und SHA-256(x ‖ padding ‖ y) berechnen, ohne x zu kennen. Diese Length Extension ist für Signaturen und HMAC harmlos, bricht aber naive MACs wie SHA-256(key ‖ message).
SHA-3 ist ein Sponge: Er absorbiert die Eingabe über die Permutation Keccak-f in einen 1600-Bit-Zustand und presst die Ausgabe aus einem Teil dieses Zustands heraus. Bei SHA3-256 bilden 1088 Bit des Zustands die Rate und 512 Bit die Kapazität, die nie ausgegeben wird; deshalb ist Length Extension unmöglich, und SHA3-256(key ‖ message) ist ein solider MAC (NIST standardisiert dafür KMAC). Derselbe Sponge liefert die Funktionen mit erweiterbarer Ausgabe SHAKE128 und SHAKE256, mit denen Post-Quanten-Algorithmen Seeds zu Matrizen und Rauschen expandieren.
NIST wählte Keccak 2012 nach einem fünfjährigen Wettbewerb aus, der begonnen hatte, als Angriffe auf MD5 und SHA-1 Befürchtungen über die ähnliche Struktur von SHA-2 weckten. Diese Befürchtungen haben sich nicht bewahrheitet: Die besten Kollisionsangriffe auf SHA-256 reichen bis etwa 31 von 64 Schritten, und die vollständige Funktion zeigt keine Schwäche. SHA-3 ist daher eine Absicherung, kein Ersatz.
Geschwindigkeit
Auf dem Apple M4 Max gibt es für beide Familien eigene Befehle, und doch ist SHA-256 bei langen Eingaben fast dreimal so schnell: etwa 2,85 GB/s gegenüber 1,01 GB/s für SHA3-256 in OpenSSL 3.6.5, während SHA3-512 auf 0,53 GB/s kommt. Auf x86-CPUs mit SHA-Erweiterungen sieht es ähnlich aus; auf Prozessoren ohne Hash-Befehle liegen SHA-3 und SHA-256 näher beieinander, und BLAKE2 oder BLAKE3 sind schneller als beide. Für die meisten Anwendungen ist jede der beiden Funktionen weit schneller als das I/O ringsherum; eine Rolle spielt das Tempo beim Hashen sehr großer Dateien, bei Merkle-Bäumen und bei Blockchains.
SHA3-256 ist nicht Keccak-256
Ethereum übernahm Keccak, bevor FIPS 202 fertig war, und FIPS 202 änderte danach das Padding (es kamen Bits zur Domain-Separation hinzu). Beide Funktionen teilen sich die Permutation, liefern aber völlig unterschiedliche Digests. keccak256 in Solidity, der RPC-Aufruf web3_sha3 sowie jede Ethereum-Adresse, jeder Funktionsselektor und jeder EIP-712-Digest verwenden Keccak-256. Rufst du in Ethereum-Code das SHA3-256 einer Bibliothek auf, erhältst du falsche Ergebnisse, ohne dass ein Fehler gemeldet wird.
import { createHash } from "node:crypto";
import { keccak_256 } from "@noble/hashes/sha3.js";
const input = Buffer.from("abc");
console.log("SHA-256 ", createHash("sha256").update(input).digest("hex"));
console.log("SHA3-256 ", createHash("sha3-256").update(input).digest("hex"));
console.log("Keccak-256", Buffer.from(keccak_256(input)).toString("hex"));
SHA-256 ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
SHA3-256 3a985da74fe225b2045c172d6bd390bd855f086e3e9d525b46bfe24511431532
Keccak-256 4e03657aea45a94fc7d47ba826c8d667c0d1e6e33a64a036ec44f58fa12d6c45
Die Werte für SHA-256 und SHA3-256 stimmen mit den Beispielen aus FIPS 180-4 und FIPS 202 für „abc“ überein.
Wann welches Verfahren passt
- Interoperabilität mit Protokollen (TLS, Zertifikate, JWT, SSH, Git, Paketmanager, Bitcoin): SHA-256, weil die Gegenseite genau das berechnet.
- Hashing mit Schlüssel: HMAC (etwa HMAC-SHA256) funktioniert mit jedem SHA-2-Hash; wenn du eine einfache Konstruktion mit Schlüssel bevorzugst, vermeiden KMAC oder SHA-3 mit Schlüssel den doppelten Durchlauf von HMAC.
- Seed-Expansion, deterministische Zufallsströme, Ausgabe variabler Länge: SHAKE256 oder SHAKE128.
- Post-Quanten-Algorithmen: was der jeweilige Standard intern festlegt; ML-KEM und ML-DSA verwenden SHA3 und SHAKE, daher enthalten Bibliotheken, die sie implementieren, SHA-3 bereits.
- Ethereum: Keccak-256, nie SHA3-256 nach FIPS.
- Ein zweiter, strukturell andersartiger Hash für Defense in Depth (zum Beispiel doppeltes Hashen von Langzeitarchiven): SHA-3 neben SHA-256.
- Reines Tempo ohne FIPS-Anforderung: BLAKE2 oder BLAKE3 auf CPUs ohne Hash-Befehle.
Hinweise zur Migration
Ein Wechsel der Hashfunktion ändert jeden Digest; es ist also eine Formatänderung, kein bloßer Austausch der Bibliothek.
- Versioniere die Kennung: Speichere zu jedem Digest den Algorithmus (
sha256:,sha3-256:, Multihash, eine OID), wie es inhaltsadressierte Systeme wie Container-Registrys und SRI tun. - Veröffentliche während der Umstellung beide Digests: Berechne beide, prüfe den, den der Empfänger kennt, und schaffe den alten ab, sobald die Empfänger umgestellt haben.
- Prüfe Annahmen zur Length Extension: Wenn Code MACs als
hash(secret ‖ message)bildet, behebt der Umstieg auf SHA-3 das Problem, der Umstieg auf HMAC behebt es aber auch für SHA-256. - Achte auf Kürzung und Kodierungen: Digests werden als Hex, base64 oder base64url übertragen; nicht passende Kodierungen sind häufiger als nicht passende Algorithmen.
- Migriere nicht allein wegen Quantencomputern: Beide Funktionen behalten auch gegen den Grover-Algorithmus eine Urbildresistenz von mindestens 128 Bit, und der Entwurf des Übergangsplans von NIST lässt beide weiter zu.