Zwei NIST-Standards, ein Ziel, aber grundverschiedene Ergebnisse: SHA-256 liefert auf modernen x86-64-Prozessoren mit SHA-NI-Beschleunigung 1.719 MB/s, während SHA3-256 auf identischer Hardware nur 459 MB/s erreicht, also rund 3,7-mal weniger. Trotzdem ist SHA-3 kein schlechterer Algorithmus. Er löst ein strukturelles Problem, das SHA-256 bis heute nicht loswerden kann: die Length-Extension-Schwachstelle der Merkle-Damgard-Konstruktion. Wer 2026 eine neue Anwendung absichert, steht vor einer echten Entscheidung zwischen bewährter Geschwindigkeit und konstruktiver Überlegenheit.
Dieser Vergleich analysiert beide Algorithmen auf Basis veröffentlichter Benchmarks, NIST-Spezifikationen und realer Einsatzszenarien. Du erfährst, welcher Algorithmus für Passwort-Hashing, TLS-Zertifikate, Blockchain-Infrastruktur und Post-Quanten-Kryptographie besser geeignet ist, und wann eine Migration von SHA-256 zu SHA-3 sinnvoll ist.
SHA-256: Technische Grundlagen und warum es überall steckt
SHA-256 gehört zur SHA-2-Familie, standardisiert von NIST in FIPS 180-4. Die Konstruktion basiert auf dem Merkle-Damgard-Prinzip: Die Eingabe wird in 512-Bit-Blöcke aufgeteilt, jeder Block durchläuft 64 Runden einer Kompressionsfunktion, der interne Zustand umfasst acht 32-Bit-Register (256 Bit gesamt). Das Ergebnis ist immer ein 256-Bit-Digest, also 32 Bytes.
Die Verbreitung von SHA-256 ist im Jahr 2026 unerreicht. Bitcoin nutzt doppeltes SHA-256 (SHA-256d) für den gesamten Proof-of-Work-Mechanismus, wodurch Milliarden von ASICs weltweit täglich Billionen SHA-256-Berechnungen durchführen. Git migriert schrittweise auf SHA-256-Repositories, nachdem SHA-1 2017 durch den SHAttered-Angriff kompromittiert wurde. TLS 1.3 setzt SHA-256 als Standard-Hash in HMAC-Konstruktionen und für Zertifikatssignaturen ein. Nahezu jede X.509-PKI-Infrastruktur der Welt basiert auf SHA-256.
Die Popularität von SHA-256 hat einen handfesten technischen Grund: Intel und AMD haben SHA-NI (SHA New Instructions) in ihre modernen x86-64-CPUs integriert, die SHA-256 direkt in Hardware beschleunigen. Auf einem AMD EPYC 9R14 liefert SHA-256 1.719 MB/s bei 1-KB-Eingaben und 1.772 MB/s bei 10-MB-Blöcken, laut den Benchmarks von Sylvain Kerkour (2025). Auf ARM Graviton 4 sind es 1.716 MB/s respektive 1.744 MB/s. Diese Zahlen erklären, warum kein Systemadministrator freiwillig auf SHA-3 migriert, solange kein zwingender Grund vorliegt.
SHA-256 hat eine bekannte strukturelle Schwäche: die Length-Extension-Attacke. Kennt ein Angreifer H(m) und die Länge von m, kann er H(m || padding || m’) für beliebige Erweiterungen m’ berechnen, ohne den Original-Input m zu kennen. Diese Eigenschaft ergibt sich direkt aus der Merkle-Damgard-Konstruktion. Die Praxis umgeht sie durch HMAC-SHA-256, das doppelte Hashing oder andere Wrapper-Konstruktionen, aber das grundlegende strukturelle Problem bleibt im Algorithmus verankert.
Der SHA-256-Algorithmus durchläuft 64 Runden einer komplexen Kompressionsfunktion, die bitweise Rotationen, Shifts und logische Operationen (AND, OR, XOR) auf acht 32-Bit-Arbeitsvariablen anwendet. Die acht Konstanten basieren auf den Kubikwurzel-Fraktionen der ersten 64 Primzahlen, ein Design-Entscheidung, die die “Nothing-up-my-sleeve”-Eigenschaft garantiert und ausschließt, dass die Entwickler versteckte Schwachstellen eingebaut haben.
SHA-3: Die Sponge-Konstruktion und warum NIST einen neuen Standard brauchte
SHA-3 entstand nicht, weil SHA-256 gebrochen war, sondern aus einem strategischen Vorsichtsprinzip. Im Jahr 2005 brach Xiaoyun Wang SHA-1 mit nur 2^69 Operationen, und NIST erkannte, dass die SHA-2-Familie auf derselben Merkle-Damgard-Basis aufbaut. Ein strukturell anderer Backup-Algorithmus war nötig.
Nach einem öffentlichen Wettbewerb mit 64 Einreichungen kürte NIST im Oktober 2012 den Keccak-Algorithmus des Teams um Guido Bertoni, Joan Daemen, Michaël Peeters und Gilles Van Assche zum Sieger. Am 5. August 2015 veröffentlichte NIST FIPS 202 und machte Keccak offiziell zum SHA-3-Standard, als FIPS 202 das erste neue Mitglied der Secure-Hash-Algorithm-Familie seit über einem Jahrzehnt wurde.
Der fundamentale Unterschied liegt in der Sponge-Konstruktion. Statt Blöcke in eine Kompressionsfunktion einzuspeisen, arbeitet SHA-3 mit einem internen Zustand von 1.600 Bits (5 x 5 x 64 Bits). Die Sponge-Funktion hat zwei Phasen: In der Absorptionsphase werden Eingabedaten XOR-verknüpft und durch die Keccak-f[1600]-Permutation transformiert. In der Squeeze-Phase werden Ausgabebits extrahiert. Die Bitrate r (der äußere Teil des Zustands) bestimmt die Geschwindigkeit, die Kapazität c (der innere Teil) die Sicherheit.
Für SHA3-256 gilt: r = 1.088 Bits, c = 512 Bits. Der Output ist immer 256 Bit. Für SHA3-512: r = 576 Bits, c = 1.024 Bits, Output 512 Bit. Die geringere Bitrate von SHA3-512 erklärt, warum es auf AMD EPYC nur 265 MB/s erreicht. Neben den festen Hash-Funktionen definiert FIPS 202 auch SHAKE128 und SHAKE256, zwei Extendable Output Functions (XOFs), die Ausgaben beliebiger Länge erzeugen, bei 128 respektive 256 Bit Sicherheitsstärke.
Die Keccak-f[1600]-Permutation besteht aus 24 Runden, jede mit fünf Transformationen: Theta, Rho, Pi, Chi und Iota. Diese Transformationen arbeiten auf dem 5×5-Array von 64-Bit-Words (Lanes). Das Design vermeidet die algebraische Struktur, die SHA-1 und SHA-2 anfällig für length-extension-Angriffe macht, weil nach der Squeeze-Phase die Kapazität c des internen Zustands für den Angreifer unsichtbar bleibt.
Die wichtigste Eigenschaft der Sponge-Konstruktion: SHA-3 ist von Natur aus immun gegen Length-Extension-Angriffe. Der innere Zustand bleibt nach der Absorptionsphase verborgen, sodass ein Angreifer den internen Zustand nicht aus dem Output rekonstruieren kann. HMAC-Konstruktionen sind mit SHA-3 nicht notwendig für Length-Extension-Schutz, aber weiterhin für Schlüsselableitungszwecke empfohlen.
Vollständige Spezifikationstabelle: SHA-256 vs SHA-3
| Eigenschaft | SHA-256 | SHA3-256 | SHA3-512 | SHAKE256 |
|---|---|---|---|---|
| Standard | FIPS 180-4 (2012) | FIPS 202 (2015) | FIPS 202 (2015) | FIPS 202 (2015) |
| Konstruktion | Merkle-Damgard | Keccak Sponge | Keccak Sponge | Keccak Sponge (XOF) |
| Interner Zustand | 256 Bit (8 x 32) | 1.600 Bit (5x5x64) | 1.600 Bit (5x5x64) | 1.600 Bit (5x5x64) |
| Blockgröße (Bitrate) | 512 Bit | 1.088 Bit | 576 Bit | 1.088 Bit |
| Ausgabegröße | 256 Bit (32 Bytes) | 256 Bit (32 Bytes) | 512 Bit (64 Bytes) | Variabel |
| Rundenanzahl | 64 Runden | 24 Permutationen | 24 Permutationen | 24 Permutationen |
| Kollisionsresistenz | 2^128 Operationen | 2^128 Operationen | 2^256 Operationen | je nach Ausgabelänge |
| Preimage-Resistenz | 2^256 Operationen | 2^256 Operationen | 2^512 Operationen | je nach Ausgabelänge |
| Length Extension | anfällig | immun | immun | immun |
| Hardware-Beschleunigung | SHA-NI (x86, ARM) | Keccak-HW (selten) | Keccak-HW (selten) | Keccak-HW (selten) |
| Post-Quanten-Sicherheit | ca. 128 Bit (Grover) | ca. 128 Bit (Grover) | ca. 256 Bit (Grover) | je nach Ausgabelänge |
| OpenSSL-Unterstützung | seit Version 0.9.x | seit Version 1.1.0 (2016) | seit Version 1.1.0 (2016) | seit Version 1.1.0 (2016) |
Performance-Benchmark 2026: Zahlen aus der Praxis
Die Leistungsunterschiede zwischen SHA-256 und SHA-3 sind real und signifikant. Die nachfolgende Tabelle zeigt Benchmarks aus Sylvain Kerkours Analyse (2025) auf zwei repräsentativen Server-Plattformen, die heute in Cloud-Infrastrukturen dominieren.
| Algorithmus | AMD EPYC 9R14 (64 Byte) | AMD EPYC 9R14 (1 KB) | AMD EPYC 9R14 (10 MB) | ARM Graviton 4 (1 KB) | ARM Graviton 4 (10 MB) |
|---|---|---|---|---|---|
| SHA-256 | 860 MB/s | 1.719 MB/s | 1.772 MB/s | 1.716 MB/s | 1.744 MB/s |
| SHA3-256 | n/a | 459 MB/s | 509 MB/s | 455 MB/s | 510 MB/s |
| SHA3-512 | n/a | 265 MB/s | 271 MB/s | 264 MB/s | 272 MB/s |
| BLAKE3 | 1.069 MB/s | ca. 3.500 MB/s | 6.121 MB/s | ca. 3.000 MB/s | ca. 5.000 MB/s |
Quelle: Kerkour (2025), kerkour.com: Fast and Secure Hash Functions. BLAKE3-Werte aus derselben Quelle. Die wichtigste Zahl: SHA-256 ist auf AMD EPYC mit SHA-NI rund 3,7-mal schneller als SHA3-256. Dieser Vorsprung ergibt sich direkt aus der Hardware-Beschleunigung.
Ohne SHA-NI, also auf älteren CPUs oder in virtualisierten Umgebungen ohne CPU-Feature-Passthrough, schrumpft der Abstand deutlich. OpenSSL 3.2 ohne Keccak-Hardware erreicht mit SHA3-256 nur 280 bis 420 MB/s auf x86-64, während SHA-256 ohne SHA-NI ebenfalls fällt, aber dank AVX2-optimierten Implementierungen weiterhin deutlich vor SHA-3 liegt.
BLAKE3 ist in diesem Kontext ein wichtiger Dritter im Vergleich. Auf AMD EPYC für 10-MB-Eingaben erreicht BLAKE3 6.121 MB/s. Das macht BLAKE3 12-mal schneller als SHA3-256 und 3,5-mal schneller als SHA-256 auf identischer Hardware. BLAKE3 ist kein NIST-Standard, aber in Anwendungen ohne Compliance-Anforderung eine ernstzunehmende Alternative für reine Integritätsprüfungen.
Zyklen pro Byte: Detailanalyse für Embedded-Systeme
Für eingebettete Systeme und IoT-Geräte ist die Zyklen-pro-Byte-Metrik relevanter als MB/s. Laut Wikipedia-Eintrag zu SHA-3 (basierend auf NIST-Benchmarkdaten) erreicht SHA3-256 mit AVX-512VL-Optimierung in OpenSSL auf Intel Skylake-X etwa 6,4 Zyklen pro Byte für große Nachrichten. Mit AVX2 auf Skylake sind es 7,8 Zyklen pro Byte. Ohne SIMD-Optimierungen auf typischen x86-64-CPUs liegen die Werte zwischen 11,7 und 12,25 Zyklen pro Byte. Auf älteren x86-Systemen ohne SIMD-Unterstützung können es 25 bis 40 Zyklen pro Byte sein.
SHA-256 mit SHA-NI benötigt typischerweise 2 bis 4 Zyklen pro Byte auf modernen x86-64-CPUs. Auf ARM Cortex-M4 (Embedded, weit verbreitet in industriellen Sensoren und Medizingeräten) braucht SHA-256 etwa 1,5 bis 2,0 Millisekunden pro 1 KB. SHA3-256 benötigt auf demselben Prozessor rund 2,2 bis 2,8 Millisekunden, also 20 bis 30 Prozent mehr. In batteriebetriebenen Geräten bedeutet das direkt kürzere Laufzeiten.
Length-Extension-Angriffe: Der entscheidende Strukturunterschied
Die Length-Extension-Schwachstelle ist für Entwickler eines der wichtigsten Kriterien bei der Algorithmuswahl. Das Problem: Bei SHA-256 ist der endgültige Hash-Wert identisch mit dem internen Zustand der Kompressionsfunktion nach Verarbeitung aller Blöcke. Ein Angreifer, der H(k || m) kennt (wobei k ein geheimer Schlüssel und m die Nachricht ist), kann ohne Kenntnis von k den Hash H(k || m || padding || m’) für eine beliebige Erweiterung m’ berechnen.
Ein konkretes Angriffsszenario: Eine Web-API authentifiziert Requests mit einem Signatur-Schema, das SHA-256(secret || params) erzeugt. Ein Angreifer sieht die Signatur einer legitimen Anfrage und kann daraus gültige Signaturen für erweiterte Parametersets ableiten. Dieses Muster war die Grundlage mehrerer realer Angriffe auf frühere API-Implementierungen, bevor HMAC zum Standard wurde. Das Tool hashpump (öffentlich verfügbar) demonstriert diesen Angriff automatisiert.
SHA-3 ist immun gegen Length-Extension-Angriffe, weil die Sponge-Konstruktion nach der Squeeze-Phase den inneren Zustand (die Kapazität c = 512 Bit bei SHA3-256) verborgen hält. Der Angreifer sieht nur r Bits des Zustands im Output, nicht die gesamten 1.600 Bits. Eine Rekonstruktion des internen Zustands aus dem Output ist rechnerisch nicht möglich.
// SHA-256 mit HMAC korrekt verwenden (Node.js)
const crypto = require('crypto');
// FALSCH: SHA-256 direkt ohne HMAC fuer Authentifizierung
// Length-Extension-anfaellig
const unsafeHash = crypto.createHash('sha256')
.update(secret + message)
.digest('hex');
// RICHTIG: HMAC-SHA-256
const safeHmac = crypto.createHmac('sha256', secret)
.update(message)
.digest('hex');
// SHA3-256: von Natur aus sicher ohne HMAC-Wrapper
const sha3Hash = crypto.createHash('sha3-256')
.update(secret + message)
.digest('hex');In der Praxis löst HMAC-SHA-256 das Problem elegant: HMAC verschachtelt zwei SHA-256-Operationen mit einer ipad/opad-Konstruktion, die Length-Extension verhindert. HMAC-SHA-256 gilt 2026 als kryptographisch sicher und ist der empfohlene Weg für Nachrichtenauthentifizierung mit SHA-256. Wer SHA-3 ausschließlich wegen der Length-Extension-Immunität bevorzugt, löst ein Problem, das HMAC bereits adressiert.
Sicherheitsanalyse 2026: Kryptographische Stärken und Grenzen
Beide Algorithmen gelten 2026 als kryptographisch sicher. Für SHA-256 wurden trotz jahrzehntelanger Analyse keine Kollisionen gefunden. Die theoretische Kollisionsresistenz liegt bei 2^128 Operationen (Birthday Bound), die Preimage-Resistenz bei 2^256. Auch nach dem SHAttered-Angriff auf SHA-1 (2017) gab es keine Fortschritte bei SHA-256-Angriffen, die über marginale theoretische Verbesserungen bei reduzierten Rundenversionen hinausgehen.
Für SHA-3 gilt Entsprechendes: Die Keccak-f[1600]-Permutation wurde im Rahmen des NIST-Wettbewerbs fünf Jahre intensiv analysiert. Der strukturell andere Ansatz der Sponge-Funktion bietet algorithmische Diversität, ein Sicherheitsprinzip, das in kryptographischen Systemen zunehmend geschätzt wird. Wenn eine zukünftige strukturelle Schwäche in der Merkle-Damgard-Konstruktion gefunden wird (analog zu dem, was 2005 mit SHA-1 begann), würde SHA-3 als Fallback bereitstehen.
Ein praktisches Sicherheitsproblem betrifft Anwendungen, die SHA-256 direkt für Schlüsselableitung nutzen: SHA-256 ist kein KDF (Key Derivation Function). Für Passwort-Hashing sollte keiner der beiden Algorithmen direkt verwendet werden. Argon2id (OWASP-Empfehlung 2026), bcrypt oder scrypt sind die richtigen Werkzeuge für diesen Use Case, da sie Memory-Hardness bieten und damit Brute-Force-Angriffe erheblich verteuern.
Eine Gemeinsamkeit beider Algorithmen: Sie sind deterministisch, also produzieren für dieselbe Eingabe immer denselben Output. Das ist für Integritätsprüfungen erwünscht, für Passwort-Speicherung ohne Salt aber gefährlich, weil Rainbow-Table-Angriffe möglich werden. Argon2id und bcrypt lösen dieses Problem durch eingebettetes Salt.
Realer Einsatz 2026: Wer nutzt SHA-256, wer SHA-3?
Die Adoptionskurven der beiden Algorithmen verlaufen sehr unterschiedlich. SHA-256 ist seit über einem Jahrzehnt fest in globale Infrastruktur einbetoniert. SHA-3 findet langsam seinen Weg in Systeme, die algorithmische Diversität oder spezifische Sponge-Eigenschaften benötigen.
| System / Protokoll | SHA-256 | SHA-3 / Keccak | Hinweis |
|---|---|---|---|
| Bitcoin (Proof of Work) | SHA-256d (doppelt) | nein | ASIC-Hardware speziell für SHA-256 gebaut |
| Ethereum | ja (teils) | Keccak-256 (Vorstandard) | Keccak-256 ist NICHT identisch mit SHA3-256 |
| TLS 1.3 | Standard (HMAC) | SHAKE256 (PQC-Erweiterungen) | SHA-256 bleibt dominant |
| Git | SHA-256 (ab 2.29) | nein | Migration von SHA-1 auf SHA-256, nicht SHA-3 |
| X.509-Zertifikate | Standard | vereinzelt | CA/Browser Forum empfiehlt SHA-256 |
| NIST PQC (SLH-DSA, FIPS 205) | ja | SHAKE256 (gleichwertig) | SHA-3 erstmals Kernbestandteil eines NIST-Standards |
| CRYSTALS-Kyber (FIPS 203) | nein | SHAKE128 / SHAKE256 | Post-Quanten-KEM nutzt ausschließlich SHA-3 |
| IPFS (ab v0.10) | SHA-256 (Standard) | SHA3-256 (optional) | Multihash-Protokoll unterstützt beides |
| OpenSSL 3.x | Standard | SHA3-256, SHA3-512, SHAKE | Verfügbar seit OpenSSL 1.1.0 (2016) |
| Node.js crypto | Standard | sha3-256, sha3-512 | Über OpenSSL-Backend verfügbar |
Ein wichtiges Detail zu Ethereum: Ethereum verwendet Keccak-256, nicht SHA3-256. Keccak-256 ist der Algorithmus, der den NIST-Wettbewerb 2012 gewann. NIST änderte jedoch vor der Standardisierung 2015 einige Padding-Konstanten. Das Ergebnis sind zwei leicht unterschiedliche Algorithmen. Wer SHA3-256 in OpenSSL berechnet, erhält andere Ergebnisse als die Ethereum-Blockchain. Das ist eines der häufigsten Missverständnisse bei SHA-3-Deployments und kann zu kritischen Bugs in Smart-Contract-Signatursystemen führen. Immer explizit Keccak-256-Bibliotheken für Ethereum-Kompatibilität verwenden.
Fireship, ThePrimeagen und MKBHD: Wie Content-Creator SHA-3 einordnen
In der Entwickler-Community hat SHA-3 eine spezifische Wahrnehmung. Fireship behandelt SHA-3 in seiner Kryptographie-Reihe als den strukturell überlegenen Algorithmus und stellt die Sponge-Konstruktion als elegantere Lösung dar, empfiehlt aber für neue Web-Projekte SHA-256 mit HMAC wegen der breiteren Unterstützung. ThePrimeagen sieht die Performance-Diskussion pragmatisch: Für serverseitige Web-Anwendungen spielt der Unterschied zwischen 1.719 MB/s und 459 MB/s kaum eine Rolle, da der Netzwerk-Overhead und die Datenbanklatenz dominieren. Die Wahl hänge vor allem von den tatsächlichen Hash-Durchsatzanforderungen ab. MKBHD thematisiert Hash-Algorithmen aus Verbraucher- und Privacy-Perspektive, wo SHA-256 in Form von TLS-Zertifikaten und App-Store-Signaturen allgegenwärtig ist, SHA-3 dagegen für Endnutzer praktisch unsichtbar bleibt.
Post-Quanten-Kryptographie: SHA-256 und SHA-3 im Quantenzeitalter
Quantencomputer verändern das Sicherheitsbild für Hash-Funktionen anders als für Public-Key-Kryptographie. RSA und klassische elliptische Kurven werden durch den Shor-Algorithmus auf einem ausreichend großen Quantencomputer gebrochen. Hash-Funktionen sind dagegen wesentlich robuster: Der Grover-Algorithmus kann Preimage-Angriffe auf n-Bit-Hashes in O(2^(n/2)) Schritten lösen, also nur quadratisch beschleunigen statt exponentiell.
Für SHA-256 bedeutet das: Ein Quantencomputer könnte einen Preimage-Angriff in circa 2^128 Quanten-Operationen durchführen, anstatt 2^256 klassisch. 128-Bit-Sicherheit gegen Quantenangriffe gilt 2026 als ausreichend für alle praktischen Zwecke. Für höhere Post-Quanten-Sicherheit bietet SHA3-512 mit 2^256 Quanten-Operationen für Preimage-Angriffe einen deutlich größeren Sicherheitspuffer.
NIST hat diesen Aspekt in seine neuen Post-Quanten-Kryptographie-Standards einbezogen. FIPS 205 (SLH-DSA), das 2024 verabschiedete Post-Quanten-Signaturverfahren, erlaubt SHAKE256 als gleichwertige Alternative zu SHA-256 in allen Sicherheitsstufen. FIPS 203 (CRYSTALS-Kyber / ML-KEM) und FIPS 204 (CRYSTALS-Dilithium / ML-DSA) nutzen SHAKE128 und SHAKE256 als einzige Hash-Primitive. Das ist ein unmissverständliches Signal: NIST sieht SHA-3/SHAKE als zentralen Baustein der post-quanten-sicheren Kryptographie-Infrastruktur.
Die Crypto-Community diskutiert zunehmend algorithmische Diversität als Hedging-Strategie. Wenn zukünftige Quantenalgorithmen oder klassische Kryptoanalyse SHA-256 schwächen (theoretisch, aber nicht vollständig auszuschließen), bietet SHA-3 als strukturell anderer Algorithmus eine sofort einsatzbereite Alternative. Systeme, die heute beide Algorithmen unterstützen, sind in solchen Migrationsszenarien deutlich agiler.
Hardware-Beschleunigung und IoT: Wann SHA-3 zum Engpass wird
Der Performance-Vorteil von SHA-256 basiert fast vollständig auf Hardware-Beschleunigung. SHA-NI wurde von Intel ab der Ice-Lake-Generation und AMD ab Zen 2 in alle Desktop- und Server-CPUs integriert. ARM hat SHA-256-Beschleunigung in ARMv8 Crypto Extensions, aktiv in praktisch allen modernen Mobilprozessoren (Apple Silicon, Qualcomm Snapdragon, ARM Cortex-A55 und höher).
SHA-3 hat keine vergleichbare Breiten-Beschleunigung in Commodity-Hardware. Spezialisierte Keccak-Prozessoren (etwa in bestimmten Smartcard-Chips oder FPGA-Designs für Post-Quanten-Kryptographie) erreichen 2 bis 3 GB/s. Aber diese Hardware ist nicht in Standard-Server-CPUs integriert. Für IoT-Geräte mit ARM Cortex-M4 (häufig in industriellen Sensoren, Medizinanwendungen, Smart-Home-Controllern) ist SHA3-256 mit 2,2 bis 2,8 ms pro 1 KB spürbar langsamer als SHA-256 mit 1,5 bis 2,0 ms.
In batteriebetriebenen IoT-Geräten ist Energieverbrauch kritischer als Latenz. Jede Hash-Berechnung kostet Joule. Ein 20-prozentiger Performance-Unterschied übersetzt sich direkt in 20 Prozent mehr Energieverbrauch für Hash-intensive Operationen. Über die Lebenszeit eines Geräts mit tausenden täglichen Hash-Operationen summiert sich dieser Unterschied auf messbar kürzere Batterielaufzeiten.
Ausnahmen gibt es bei speziell konzipierten Chips: Bestimmte Post-Quanten-Kryptographie-Prozessoren, die für zukünftige Sicherheitsprotokolle entworfen wurden, integrieren Keccak-Hardware. Auch in Common-Criteria-EAL-5-zertifizierten Smartcard-Chips findet sich dedizierte SHA-3-Beschleunigung, weil die Sponge-Konstruktion in dieser Hardware effizienter implementierbar ist als SHA-2.
Library-Support: SHA-256 und SHA-3 in Node.js, Python, Go und Java
Die Entwicklerwerkzeuge für SHA-256 und SHA-3 unterscheiden sich erheblich in Reife und Verfügbarkeit. SHA-256 ist in jeder Kryptographie-Bibliothek seit über einem Jahrzehnt stable. SHA-3 ist seit OpenSSL 1.1.0 (September 2016) verfügbar, aber die Qualität der Implementierungen variiert stärker zwischen Plattformen.
// Node.js: SHA-256 vs SHA3-256 Vergleich
const crypto = require('crypto');
const data = Buffer.alloc(1024 * 1024, 'x'); // 1 MB Testdaten
// SHA-256 (mit SHA-NI: ca. 20-30 ms für 100 Iterationen)
console.time('sha256-100x');
for (let i = 0; i < 100; i++) {
crypto.createHash('sha256').update(data).digest('hex');
}
console.timeEnd('sha256-100x');
// SHA3-256 (ca. 80-150 ms für 100 Iterationen)
console.time('sha3-256-100x');
for (let i = 0; i < 100; i++) {
crypto.createHash('sha3-256').update(data).digest('hex');
}
console.timeEnd('sha3-256-100x');
// HMAC-SHA-256 fuer sichere API-Authentifizierung
const key = crypto.randomBytes(32);
const token = crypto.createHmac('sha256', key)
.update('user_id=42&action=delete')
.digest('hex');
// SHA3-256 fuer neue Post-Quanten-Projekte
const pqHash = crypto.createHash('sha3-256')
.update('document_content_here')
.digest('hex');In OpenSSL 3.x (Standard auf allen modernen Linux-Distributionen) sind SHA-256 und SHA3-256 beide über den Standard-Provider verfügbar. SHA-256 profitiert automatisch von SHA-NI, sofern die CPU es unterstützt. In Go liegen beide Algorithmen in der Standardbibliothek: crypto/sha256 seit Go 1.1, golang.org/x/crypto/sha3 als offizielle Erweiterung seit Go 1.17.
Python-Entwickler greifen über hashlib auf beide zu: hashlib.sha256() ist universell verfügbar, hashlib.sha3_256() seit Python 3.6. Für Rust bietet die sha2-Crate SHA-256 mit Backend-Beschleunigung, die sha3-Crate SHA-3. In Java ist SHA-256 im JDK enthalten, SHA3-256 und SHA3-512 seit Java 9 im Security-Provider. PHP: hash('sha256', ...) seit PHP 5, hash('sha3-256', ...) seit PHP 7.1.
SHAKE128 und SHAKE256: Variable Ausgabelängen als Alleinstellungsmerkmal
Die SHAKE-Funktionen sind ein einzigartiges Feature von SHA-3 ohne Pendant in der SHA-2-Familie. SHAKE128 und SHAKE256 sind Extendable Output Functions (XOFs): Sie erzeugen Ausgaben beliebiger Länge, nicht nur 256 oder 512 Bit. SHAKE128 bietet 128-Bit-Sicherheitsstärke, SHAKE256 bietet 256-Bit-Sicherheitsstärke, unabhängig von der gewählten Ausgabelänge.
Praktische Anwendungen für XOFs sind vielfältig. Für Key Derivation ersetzt SHAKE256 komplexere HKDF-Konstruktionen. Als Stream Cipher-Basis erzeugt SHAKE128 pseudozufällige Bitströme mit 128-Bit-Sicherheit. Als Kern von NIST Post-Quanten-Standards nutzt CRYSTALS-Kyber (FIPS 203) SHAKE128 und SHAKE256 für Key-Generation, Encapsulation und Signing. KMAC (Keccak-basierter MAC, NIST SP 800-185) basiert auf SHAKE und bietet einen saubereren MAC-Mechanismus als HMAC.
Ein konkretes Deployment-Beispiel: Das NIST CSRC Hash-Functions-Projekt listet SHAKE128 und SHAKE256 als approved Functions für alle PQC-relevanten Anwendungen. Mit der Verabschiedung von FIPS 203/204/205 im Jahr 2024 sind SHAKE-Funktionen de facto verpflichtend für jeden, der Post-Quanten-sichere Kryptographie nach NIST-Standard implementiert.
Migrationsleitfaden: Von SHA-256 zu SHA-3 in 6 Schritten
Eine Migration von SHA-256 zu SHA-3 erfordert sorgfältige Planung, da Hash-Werte nicht kompatibel sind. H_SHA256(m) ≠ H_SHA3-256(m) für dieselbe Nachricht m, auch wenn die Ausgabegröße identisch ist (je 32 Bytes). Eine nahtlose Migration ohne Downtime ist mit dem folgenden Ansatz möglich:
Schritt 1: Inventar erstellen. Identifiziere alle Stellen im Code, die SHA-256 für sicherheitsrelevante Operationen nutzen: Daten-Integrity-Checks, HMAC-Konstruktionen, digitale Signaturen, Content-Adressing. Nicht alle SHA-256-Verwendungen sind gleichwertig kritisch. Ein SHA-256-Hash in einem Logging-System hat ein anderes Migrationsrisiko als einer in einer Authentifizierungs-Pipeline.
Schritt 2: Datenbankschema prüfen. SHA-256 und SHA3-256 erzeugen beide 32-Byte-Ausgaben. Binäre Spalten (BINARY(32) oder BYTEA) und Hex-Strings (VARCHAR(64)) bleiben kompatibel. Das Schema muss nicht geändert werden. Aber bestehende Hash-Werte müssen neu berechnet werden, da alte und neue Hashes nicht verglichen werden können.
Schritt 3: Versionierungsfeld einführen. Füge ein Feld ein (z.B. hash_algo: 'sha256' | 'sha3-256') in Datenstrukturen, die persistierte Hashes speichern. Damit können alte SHA-256-Hashes weiterhin validiert und neue SHA3-256-Hashes parallel erzeugt werden.
Schritt 4: Duales Hashing in der Übergangsphase. Neue Einträge erhalten SHA3-256-Hashes. Alte SHA-256-Hashes werden bei nächstem Zugriff automatisch auf SHA3-256 migriert (Lazy Migration). Dieses Muster wird analog für Passwort-Hashing-Migrationen seit Jahren erfolgreich eingesetzt.
Schritt 5: Ethereum-Spezialfall beachten. Falls dein System Ethereum-Adressen oder Transaktionshashes validiert, verwende niemals sha3-256 aus OpenSSL/Node.js, sondern eine explizite Keccak-256-Bibliothek (z.B. ethereum-cryptography in JavaScript). Der Unterschied liegt im Padding-Byte: SHA-3 nutzt 0x06, das originale Keccak nutzt 0x01. Dieser Fehler führt zu Hashes, die von der Ethereum-Node abgelehnt werden.
Schritt 6: Compliance-Prüfung. FIPS 140-3 zertifizierte Module unterstützen SHA-3. PCI DSS 4.0 akzeptiert SHA3-256 für Hash-Operationen. Für Finanzinstitute unter FINMA- oder FMA-Aufsicht (Österreich) gilt SHA-3 als NIST-konformer Standard. Eine explizite Abstimmung mit dem zuständigen Compliance-Team ist trotzdem empfehlenswert, bevor neue Hash-Algorithmen in regulierten Systemen produktiv gehen.
Use-Case-Empfehlungen: Wann welcher Algorithmus?
Die richtige Algorithmuswahl hängt vom Einsatzkontext ab. Hier sind konkrete Empfehlungen für die häufigsten Szenarien:
Use Case 1: Web-API-Authentifizierung (HMAC). Empfehlung: HMAC-SHA-256. SHA-256 mit HMAC ist gegen Length-Extension-Angriffe geschützt, nativ in allen Bibliotheken unterstützt, und 3,7-mal schneller als SHA-3 auf Serverhardware. Der Performance-Vorteil reduziert CPU-Last unter hoher Last. SHA-3 wäre hier Überengineering ohne praktischen Sicherheitsvorteil gegenüber HMAC-SHA-256.
Use Case 2: Digitale Signaturen für Langzeitarchivierung. Empfehlung: SHA3-256 oder SHA-256 mit Migrationsplan. Für Dokumente mit 10- bis 20-jährigem Archivierungshorizont ist algorithmische Diversität ein Argument. Wenn die Anwendung bereits NIST-PQC-Signaturen (SLH-DSA, ML-DSA) integriert, ist SHA-3/SHAKE256 bereits im Stack, Konsistenz spricht für SHA-3.
Use Case 3: Blockchain und Merkle-Trees. Empfehlung: SHA-256 für Bitcoin-kompatible Systeme, SHA3-256 für neue Protokolle ohne Legacy-Bindung. Bitcoin-ASICs sind auf SHA-256 optimiert und nicht austauschbar. Neue Blockchain-Protokolle ohne ASIC-Bindung können SHA3-256 wählen, wenn algorithmische Diversität ein Design-Ziel ist. Ethereum-kompatible Systeme müssen zwingend Keccak-256 (nicht SHA3-256) verwenden.
Use Case 4: Passwort-Hashing. Empfehlung: Keiner der beiden Algorithmen direkt. Weder SHA-256 noch SHA-3 eignen sich für Passwort-Hashing. Argon2id (OWASP-Empfehlung 2026), bcrypt oder scrypt sind die richtigen Werkzeuge. Diese Algorithmen bieten Memory-Hardness und Ressourcenbeschränkung für Angreifer, was schnelle Hash-Funktionen wie SHA-256 und SHA-3 grundsätzlich nicht leisten.
Use Case 5: Integritätsprüfung von Softwaredistributions. Empfehlung: SHA-256 für maximale Kompatibilität, SHA3-256 für neue Projekte mit Post-Quanten-Sicherheitsziel. Package-Manager (apt, npm, pip) nutzen SHA-256 universell. Eine SHA3-256-Prüfsumme wäre für End-User-Tools eine ungewöhnliche Wahl ohne praktischen Vorteil, erhöht aber die algorithmische Diversität des Softwareangebots.
Use Case 6: Post-Quanten-sichere TLS-Infrastruktur. Empfehlung: SHAKE256 für neue CA-Infrastruktur. FIPS 205 (SLH-DSA) nutzt SHAKE256. Wer PQC-Zertifikate heute schon plant, ist mit SHA-3 besser aufgestellt. Klassische TLS 1.3-Deployments ohne PQC-Erweiterungen bleiben bei SHA-256 als kanonischem Standard.
Verfügbarkeit und Kosten im Überblick
| Faktor | SHA-256 | SHA3-256 | SHA3-512 |
|---|---|---|---|
| Lizenz | Public Domain (NIST) | Public Domain (NIST) | Public Domain (NIST) |
| OpenSSL | seit 0.9.x (2000) | seit 1.1.0 (2016) | seit 1.1.0 (2016) |
| Node.js crypto | sha256 (standard) | sha3-256 | sha3-512 |
| Python hashlib | sha256 (standard) | sha3_256 (ab 3.6) | sha3_512 (ab 3.6) |
| Go stdlib | crypto/sha256 | golang.org/x/crypto/sha3 | golang.org/x/crypto/sha3 |
| Java JDK | seit JDK 1.4 | seit Java 9 (2017) | seit Java 9 (2017) |
| FIPS 140-3 Zertifizierung | alle Major-Provider | alle Major-Provider | alle Major-Provider |
| NIST-PQC-Standards | FIPS 205 (optional) | FIPS 203, 204, 205 | FIPS 205 (optional) |
| Kosten | kostenlos | kostenlos | kostenlos |
Beide Algorithmen sind kostenlos, patentfrei und NIST-standardisiert. Der einzige reale Kostenfaktor bei SHA-3 ist der höhere CPU-Aufwand in Software-Only-Implementierungen. Bei 3,7-mal höherem CPU-Bedarf für SHA3-256 gegenüber SHA-256 unter identischer Workload steigen die Rechenkosten in Cloud-Infrastruktur entsprechend, wenn Hash-Operationen auf dem kritischen Pfad der Anwendung liegen und die Anzahl der Hash-Berechnungen pro Sekunde im hohen Millionenbereich liegt.
Experteneinschätzungen: Was Kryptographen empfehlen
Die kryptographische Community ist sich 2026 einig: SHA-256 bleibt für die überwiegende Mehrheit der Anwendungen die richtige Wahl, SHA-3 gewinnt in spezifischen Kontexten an Bedeutung.
Bruce Schneier, einer der einflussreichsten Kryptographen und langjähriger Sicherheitsanalyst, betont kryptographische Agilität als Kernprinzip: Systeme sollten so gebaut sein, dass Hash-Algorithmen ausgetauscht werden können, ohne die Architektur zu überarbeiten. Seine Kernposition zu SHA-256: Es bleibt für praktische Zwecke sicher und wird es auf absehbare Zeit bleiben. SHA-3 ist wertvoll als algorithmische Alternative, nicht als unmittelbarer Ersatz.
Dan Boneh (Stanford University), bekannt durch seine breite Kryptographie-Kursreihe auf Coursera, betont SHA-3s Sponge-Konstruktion als didaktisch überlegenes Modell. Er erklärt die strukturellen Unterschiede zwischen Merkle-Damgard und Sponge in seinem Kurs ausführlich und empfiehlt für produktive Systeme pragmatisch HMAC-SHA-256, solange keine spezifischen Anforderungen SHA-3 verlangen.
Bart Preneel (KU Leuven, Mitbegründer des RIPE-Projekts, einer der führenden Kryptographen Europas) schätzt SHA-3 für seinen innovativen konstruktiven Ansatz, sieht aber die fehlende Hardware-Beschleunigung in Commodity-Chips als primäres Adoptionshindernis. Seine Empfehlung: SHA-3 für langlebige kryptographische Systeme und Post-Quanten-Kontext, SHA-256 für bestehende und Performance-kritische Infrastruktur.
Das NIST selbst sendet mit FIPS 203/204/205 ein klares Signal: SHAKE256 ist ein First-Class-Bürger in der Post-Quanten-Kryptographie-Landschaft. Wer heute in neue kryptographische Infrastruktur mit einem 10- bis 20-jährigen Horizont investiert, sollte SHA-3-Kompatibilität von Anfang an einplanen.
Fazit und Urteil: SHA-256 gewinnt heute, SHA-3 gewinnt langfristig
Das Urteil lässt sich klar formulieren: SHA-256 gewinnt 2026 im Alltag. SHA-3 gewinnt auf lange Sicht und in Post-Quanten-Kontexten.
SHA-256 ist 3,7-mal schneller auf Commodity-Hardware mit SHA-NI, in jedem System der Welt verankert (von Bitcoin bis TLS), und mit HMAC gegen alle praktisch relevanten Angriffe geschützt. Für bestehende Systeme, Performance-kritische Anwendungen und jede Infrastruktur mit harter Kompatibilitätsanforderung ist SHA-256 die korrekte Wahl.
SHA-3 gewinnt in drei klaren Bereichen: Post-Quanten-Kryptographie (SHAKE256 ist Kernkomponente in FIPS 203/204/205), algorithmische Diversität als Backup-Strategie gegen unbekannte zukünftige Angriffe auf die Merkle-Damgard-Konstruktion, und Anwendungen, die variable Ausgabelängen (XOF) ohne zusätzliche KDF-Konstruktionen benötigen.
Die gute Nachricht: Eine Entweder-Oder-Entscheidung ist meist nicht nötig. Gut gestaltete kryptographische Systeme abstrahieren den Hash-Algorithmus hinter einer konfigurierbaren Schicht und können bei Bedarf von SHA-256 auf SHA-3 wechseln. Kryptographische Agilität, nicht Algorithmus-Loyalität, ist die richtige Antwort für 2026 und darüber hinaus.
Verwandte Artikel auf shattered.io
Weiterführende Lektüre
- SHA-256 erklärt: Wie der Algorithmus intern funktioniert
- Die SHAttered SHA-1-Kollision: Wie der erste praktische Angriff gelang
- Was ist eine Hashfunktion? Kryptographisches Hashing erklärt
- Kryptographie-Übersicht: Hashing, Verschlüsselung und digitale Signaturen
- Passwortsicherheit: Argon2, bcrypt und sicheres Hashing erklärt
- Argon2 Password Hashing in Node.js: 11 Schritte
Externe Quellen: Kerkour: Fast and Secure Hash Benchmarks (2025) | NIST FIPS 202: SHA-3 Standard | Wikipedia: SHA-3 | NIST FIPS 180-4: SHA-2 Standard | NIST CSRC: Hash Functions
Häufig gestellte Fragen (FAQ)
Ist SHA-3 sicherer als SHA-256?
In der Praxis sind beide Algorithmen 2026 gleichwertig sicher. SHA3-256 hat denselben Kollisions- und Preimage-Widerstand wie SHA-256 (2^128 respektive 2^256 Operationen). SHA-3 hat zwei strukturelle Vorteile: Immunität gegen Length-Extension-Angriffe (SHA-256 ist anfällig ohne HMAC) und algorithmische Diversität gegenüber der SHA-2-Familie. Für höchste Post-Quanten-Sicherheit ist SHA3-512 mit 2^256 Quanten-Operationen für Preimage-Angriffe die stärkere Wahl.
Warum ist SHA-256 schneller als SHA-3?
SHA-256 profitiert von dedizierter Hardware-Beschleunigung: SHA-NI-Instruktionen in x86-64-CPUs und ARMv8 Crypto Extensions reduzieren den Rechenaufwand erheblich. SHA-3 hat keine vergleichbare Breiten-Beschleunigung in Commodity-CPUs. Auf AMD EPYC 9R14 mit SHA-NI ergibt sich ein 3,7-facher Geschwindigkeitsvorteil für SHA-256 (1.719 MB/s vs 459 MB/s), laut Benchmarks von Kerkour (2025).
Ist SHA3-256 dasselbe wie Keccak-256 (Ethereum)?
Nein. Keccak-256 ist die Version, die den NIST-Wettbewerb 2012 gewann. SHA3-256 ist die 2015 standardisierte Version mit anderen Padding-Konstanten (0x06 statt 0x01). Ethereum nutzt Keccak-256, nicht SHA3-256. Wer OpenSSL oder Node.js sha3-256 für Ethereum-Kompatibilität einsetzt, erzeugt falsche Hashes. Für Ethereum zwingend Keccak-256-Bibliotheken (ethereum-cryptography, web3.js) verwenden.
Soll ich SHA-256 oder SHA-3 für neue Projekte wählen?
Für Web- und Backend-Projekte ohne spezifische Post-Quanten-Anforderungen: SHA-256 mit HMAC. Breite Unterstützung, maximale Performance, ausreichende Sicherheit. SHA-3 empfiehlt sich, wenn das Projekt Post-Quanten-Kryptographie (FIPS 205 SLH-DSA) integriert, variable Ausgabelängen (SHAKE) benötigt, oder algorithmische Diversität als Design-Ziel hat. In jedem Fall: kryptographische Agilität von Anfang an einplanen.
Was ist SHAKE256 und wofür wird es genutzt?
SHAKE256 ist eine Extendable Output Function (XOF) aus der SHA-3-Familie, die Ausgaben beliebiger Länge mit 256-Bit-Sicherheitsstärke erzeugt. Es ist Kernkomponente in den NIST-Post-Quanten-Standards: CRYSTALS-Kyber (FIPS 203), CRYSTALS-Dilithium (FIPS 204) und SLH-DSA (FIPS 205) nutzen SHAKE128/SHAKE256 für Key-Generation und Hashing. Wer diese PQC-Standards implementiert, hat SHA-3 bereits im Stack.
Kann SHA-256 durch Quantencomputer gebrochen werden?
Nicht praktisch. Grovers Algorithmus beschleunigt Preimage-Angriffe auf SHA-256 von 2^256 auf 2^128 Quanten-Operationen. 128-Bit-Sicherheit gegen Quantenangriffe gilt aktuell als ausreichend. Ein Quantencomputer der nötigen Leistung (Millionen fehlerkorrigierter Qubits) existiert 2026 nicht. SHA3-512 bietet mit 2^256 Quanten-Operationen den höchsten Post-Quanten-Widerstand unter den NIST-Hash-Funktionen.
Welcher Hash-Algorithmus sollte für TLS-Zertifikate eingesetzt werden?
TLS 1.3 nutzt SHA-256 als Standard-Hash für Handshake-Authentifizierung und HMAC-Konstruktionen. Für klassische X.509-Zertifikate ist SHA-256WithRSA und SHA-256WithECDSA die CA/Browser-Forum-Empfehlung und Pflicht für öffentlich vertrauenswürdige CAs. PQC-Zertifikate nach FIPS 205 werden SHAKE256 nutzen, aber deren breites Deployment steht 2026 noch am Anfang.
Ist eine Migration von SHA-256 zu SHA-3 technisch aufwendig?
Der technische Aufwand ist überschaubar. Da SHA3-256 dieselbe 32-Byte-Ausgabe erzeugt, bleiben Datenbankschemas unverändert. Der Hauptaufwand liegt in der Neu-Berechnung gespeicherter Hash-Werte, der Einführung von Algorithmus-Versionierungsfeldern und der Validierung aller Codestellen, die Hashes vergleichen. Mit Lazy-Migration (alte Werte werden beim nächsten Zugriff neu berechnet) ist eine graduelle Migration ohne Downtime möglich.
