{"id":123,"date":"2026-06-18T12:25:51","date_gmt":"2026-06-18T12:25:51","guid":{"rendered":"https:\/\/shattered.io\/at\/2026\/06\/18\/sha-256-vs-sha-3\/"},"modified":"2026-06-18T12:27:24","modified_gmt":"2026-06-18T12:27:24","slug":"sha-256-vs-sha-3","status":"publish","type":"post","link":"https:\/\/shattered.io\/at\/sha-256-vs-sha-3\/","title":{"rendered":"SHA-256 vs SHA-3: 3,7x Geschwindigkeit, ein Sieger [2026]"},"content":{"rendered":"\n

Zwei NIST-Standards, ein Ziel, aber grundverschiedene Ergebnisse: SHA-256 liefert auf modernen x86-64-Prozessoren mit SHA-NI-Beschleunigung 1.719 MB\/s<\/strong>, w\u00e4hrend 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\u00f6st 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\u00e4hrter Geschwindigkeit und konstruktiver \u00dcberlegenheit.<\/p>\n\n\n\n

Dieser Vergleich analysiert beide Algorithmen auf Basis ver\u00f6ffentlichter Benchmarks, NIST-Spezifikationen und realer Einsatzszenarien. Du erf\u00e4hrst, welcher Algorithmus f\u00fcr 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.<\/p>\n\n\n\n

SHA-256: Technische Grundlagen und warum es \u00fcberall steckt<\/h2>\n\n\n\n

SHA-256 geh\u00f6rt zur SHA-2-Familie, standardisiert von NIST in FIPS 180-4<\/a>. Die Konstruktion basiert auf dem Merkle-Damgard-Prinzip: Die Eingabe wird in 512-Bit-Bl\u00f6cke aufgeteilt, jeder Block durchl\u00e4uft 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.<\/p>\n\n\n\n

Die Verbreitung von SHA-256 ist im Jahr 2026 unerreicht. Bitcoin<\/strong> nutzt doppeltes SHA-256 (SHA-256d) f\u00fcr den gesamten Proof-of-Work-Mechanismus, wodurch Milliarden von ASICs weltweit t\u00e4glich Billionen SHA-256-Berechnungen durchf\u00fchren. Git<\/strong> migriert schrittweise auf SHA-256-Repositories, nachdem SHA-1 2017 durch den SHAttered-Angriff kompromittiert wurde. TLS 1.3<\/strong> setzt SHA-256 als Standard-Hash in HMAC-Konstruktionen und f\u00fcr Zertifikatssignaturen ein. Nahezu jede X.509-PKI-Infrastruktur der Welt basiert auf SHA-256.<\/p>\n\n\n\n

Die Popularit\u00e4t von SHA-256 hat einen handfesten technischen Grund: Intel und AMD haben SHA-NI (SHA New Instructions) in ihre modernen x86-64-CPUs integriert<\/strong>, 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\u00f6cken, 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\u00e4ren, warum kein Systemadministrator freiwillig auf SHA-3 migriert, solange kein zwingender Grund vorliegt.<\/p>\n\n\n\n

SHA-256 hat eine bekannte strukturelle Schw\u00e4che: die Length-Extension-Attacke<\/strong>. Kennt ein Angreifer H(m) und die L\u00e4nge von m, kann er H(m || padding || m’) f\u00fcr 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.<\/p>\n\n\n\n

Der SHA-256-Algorithmus durchl\u00e4uft 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\u00dft, dass die Entwickler versteckte Schwachstellen eingebaut haben.<\/p>\n\n\n\n

SHA-3: Die Sponge-Konstruktion und warum NIST einen neuen Standard brauchte<\/h2>\n\n\n\n

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\u00f6tig.<\/p>\n\n\n\n

Nach einem \u00f6ffentlichen Wettbewerb mit 64 Einreichungen k\u00fcrte NIST im Oktober 2012 den Keccak-Algorithmus<\/strong> des Teams um Guido Bertoni, Joan Daemen, Micha\u00ebl Peeters und Gilles Van Assche zum Sieger. Am 5. August 2015 ver\u00f6ffentlichte NIST FIPS 202<\/strong> und machte Keccak offiziell zum SHA-3-Standard, als FIPS 202<\/a> das erste neue Mitglied der Secure-Hash-Algorithm-Familie seit \u00fcber einem Jahrzehnt wurde.<\/p>\n\n\n\n

Der fundamentale Unterschied liegt in der Sponge-Konstruktion<\/strong>. Statt Bl\u00f6cke in eine Kompressionsfunktion einzuspeisen, arbeitet SHA-3 mit einem internen Zustand von 1.600 Bits (5 x 5 x 64 Bits)<\/strong>. Die Sponge-Funktion hat zwei Phasen: In der Absorptionsphase werden Eingabedaten XOR-verkn\u00fcpft und durch die Keccak-f[1600]-Permutation transformiert. In der Squeeze-Phase werden Ausgabebits extrahiert. Die Bitrate r (der \u00e4u\u00dfere Teil des Zustands) bestimmt die Geschwindigkeit, die Kapazit\u00e4t c (der innere Teil) die Sicherheit.<\/p>\n\n\n\n

F\u00fcr SHA3-256 gilt: r = 1.088 Bits, c = 512 Bits. Der Output ist immer 256 Bit. F\u00fcr SHA3-512: r = 576 Bits, c = 1.024 Bits, Output 512 Bit. Die geringere Bitrate von SHA3-512 erkl\u00e4rt, warum es auf AMD EPYC nur 265 MB\/s erreicht. Neben den festen Hash-Funktionen definiert FIPS 202 auch SHAKE128 und SHAKE256<\/strong>, zwei Extendable Output Functions (XOFs)<\/em>, die Ausgaben beliebiger L\u00e4nge erzeugen, bei 128 respektive 256 Bit Sicherheitsst\u00e4rke.<\/p>\n\n\n\n

Die Keccak-f[1600]-Permutation besteht aus 24 Runden, jede mit f\u00fcnf 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\u00e4llig f\u00fcr length-extension-Angriffe macht, weil nach der Squeeze-Phase die Kapazit\u00e4t c des internen Zustands f\u00fcr den Angreifer unsichtbar bleibt.<\/p>\n\n\n\n

Die wichtigste Eigenschaft der Sponge-Konstruktion: SHA-3 ist von Natur aus immun gegen Length-Extension-Angriffe<\/strong>. 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\u00fcr Length-Extension-Schutz, aber weiterhin f\u00fcr Schl\u00fcsselableitungszwecke empfohlen.<\/p>\n\n\n\n

Vollst\u00e4ndige Spezifikationstabelle: SHA-256 vs SHA-3<\/h2>\n\n\n\n
Eigenschaft<\/th>SHA-256<\/th>SHA3-256<\/th>SHA3-512<\/th>SHAKE256<\/th><\/tr><\/thead>
Standard<\/td>FIPS 180-4 (2012)<\/td>FIPS 202 (2015)<\/td>FIPS 202 (2015)<\/td>FIPS 202 (2015)<\/td><\/tr>
Konstruktion<\/td>Merkle-Damgard<\/td>Keccak Sponge<\/td>Keccak Sponge<\/td>Keccak Sponge (XOF)<\/td><\/tr>
Interner Zustand<\/td>256 Bit (8 x 32)<\/td>1.600 Bit (5x5x64)<\/td>1.600 Bit (5x5x64)<\/td>1.600 Bit (5x5x64)<\/td><\/tr>
Blockgr\u00f6\u00dfe (Bitrate)<\/td>512 Bit<\/td>1.088 Bit<\/td>576 Bit<\/td>1.088 Bit<\/td><\/tr>
Ausgabegr\u00f6\u00dfe<\/td>256 Bit (32 Bytes)<\/td>256 Bit (32 Bytes)<\/td>512 Bit (64 Bytes)<\/td>Variabel<\/td><\/tr>
Rundenanzahl<\/td>64 Runden<\/td>24 Permutationen<\/td>24 Permutationen<\/td>24 Permutationen<\/td><\/tr>
Kollisionsresistenz<\/td>2^128 Operationen<\/td>2^128 Operationen<\/td>2^256 Operationen<\/td>je nach Ausgabel\u00e4nge<\/td><\/tr>
Preimage-Resistenz<\/td>2^256 Operationen<\/td>2^256 Operationen<\/td>2^512 Operationen<\/td>je nach Ausgabel\u00e4nge<\/td><\/tr>
Length Extension<\/td>anf\u00e4llig<\/td>immun<\/td>immun<\/td>immun<\/td><\/tr>
Hardware-Beschleunigung<\/td>SHA-NI (x86, ARM)<\/td>Keccak-HW (selten)<\/td>Keccak-HW (selten)<\/td>Keccak-HW (selten)<\/td><\/tr>
Post-Quanten-Sicherheit<\/td>ca. 128 Bit (Grover)<\/td>ca. 128 Bit (Grover)<\/td>ca. 256 Bit (Grover)<\/td>je nach Ausgabel\u00e4nge<\/td><\/tr>
OpenSSL-Unterst\u00fctzung<\/td>seit Version 0.9.x<\/td>seit Version 1.1.0 (2016)<\/td>seit Version 1.1.0 (2016)<\/td>seit Version 1.1.0 (2016)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Performance-Benchmark 2026: Zahlen aus der Praxis<\/h2>\n\n\n\n

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\u00e4sentativen Server-Plattformen, die heute in Cloud-Infrastrukturen dominieren.<\/p>\n\n\n\n

Algorithmus<\/th>AMD EPYC 9R14 (64 Byte)<\/th>AMD EPYC 9R14 (1 KB)<\/th>AMD EPYC 9R14 (10 MB)<\/th>ARM Graviton 4 (1 KB)<\/th>ARM Graviton 4 (10 MB)<\/th><\/tr><\/thead>
SHA-256<\/td>860 MB\/s<\/td>1.719 MB\/s<\/td>1.772 MB\/s<\/td>1.716 MB\/s<\/td>1.744 MB\/s<\/td><\/tr>
SHA3-256<\/td>n\/a<\/td>459 MB\/s<\/td>509 MB\/s<\/td>455 MB\/s<\/td>510 MB\/s<\/td><\/tr>
SHA3-512<\/td>n\/a<\/td>265 MB\/s<\/td>271 MB\/s<\/td>264 MB\/s<\/td>272 MB\/s<\/td><\/tr>
BLAKE3<\/td>1.069 MB\/s<\/td>ca. 3.500 MB\/s<\/td>6.121 MB\/s<\/td>ca. 3.000 MB\/s<\/td>ca. 5.000 MB\/s<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Quelle: Kerkour (2025), kerkour.com: Fast and Secure Hash Functions<\/a>. 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<\/strong>. Dieser Vorsprung ergibt sich direkt aus der Hardware-Beschleunigung.<\/p>\n\n\n\n

Ohne SHA-NI, also auf \u00e4lteren 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\u00e4hrend SHA-256 ohne SHA-NI ebenfalls f\u00e4llt, aber dank AVX2-optimierten Implementierungen weiterhin deutlich vor SHA-3 liegt.<\/p>\n\n\n\n

BLAKE3 ist in diesem Kontext ein wichtiger Dritter im Vergleich. Auf AMD EPYC f\u00fcr 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<\/strong> auf identischer Hardware. BLAKE3 ist kein NIST-Standard, aber in Anwendungen ohne Compliance-Anforderung eine ernstzunehmende Alternative f\u00fcr reine Integrit\u00e4tspr\u00fcfungen.<\/p>\n\n\n\n

Zyklen pro Byte: Detailanalyse f\u00fcr Embedded-Systeme<\/h3>\n\n\n\n

F\u00fcr eingebettete Systeme und IoT-Ger\u00e4te 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<\/strong> f\u00fcr gro\u00dfe 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 \u00e4lteren x86-Systemen ohne SIMD-Unterst\u00fctzung k\u00f6nnen es 25 bis 40 Zyklen pro Byte sein.<\/p>\n\n\n\n

SHA-256 mit SHA-NI ben\u00f6tigt typischerweise 2 bis 4 Zyklen pro Byte auf modernen x86-64-CPUs. Auf ARM Cortex-M4 (Embedded, weit verbreitet in industriellen Sensoren und Medizinger\u00e4ten) braucht SHA-256 etwa 1,5 bis 2,0 Millisekunden pro 1 KB. SHA3-256 ben\u00f6tigt auf demselben Prozessor rund 2,2 bis 2,8 Millisekunden, also 20 bis 30 Prozent mehr. In batteriebetriebenen Ger\u00e4ten bedeutet das direkt k\u00fcrzere Laufzeiten.<\/p>\n\n\n\n

Length-Extension-Angriffe: Der entscheidende Strukturunterschied<\/h2>\n\n\n\n

Die Length-Extension-Schwachstelle ist f\u00fcr Entwickler eines der wichtigsten Kriterien bei der Algorithmuswahl. Das Problem: Bei SHA-256 ist der endg\u00fcltige Hash-Wert identisch mit dem internen Zustand der Kompressionsfunktion nach Verarbeitung aller Bl\u00f6cke. Ein Angreifer, der H(k || m) kennt (wobei k ein geheimer Schl\u00fcssel und m die Nachricht ist), kann ohne Kenntnis von k den Hash H(k || m || padding || m’) f\u00fcr eine beliebige Erweiterung m’ berechnen.<\/p>\n\n\n\n

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\u00fcltige Signaturen f\u00fcr erweiterte Parametersets ableiten. Dieses Muster war die Grundlage mehrerer realer Angriffe auf fr\u00fchere API-Implementierungen, bevor HMAC zum Standard wurde. Das Tool hashpump<\/code> (\u00f6ffentlich verf\u00fcgbar) demonstriert diesen Angriff automatisiert.<\/p>\n\n\n\n

SHA-3 ist immun gegen Length-Extension-Angriffe<\/strong>, weil die Sponge-Konstruktion nach der Squeeze-Phase den inneren Zustand (die Kapazit\u00e4t c = 512 Bit bei SHA3-256) verborgen h\u00e4lt. 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\u00f6glich.<\/p>\n\n\n\n

\/\/ SHA-256 mit HMAC korrekt verwenden (Node.js)\nconst crypto = require('crypto');\n\n\/\/ FALSCH: SHA-256 direkt ohne HMAC fuer Authentifizierung\n\/\/ Length-Extension-anfaellig\nconst unsafeHash = crypto.createHash('sha256')\n  .update(secret + message)\n  .digest('hex');\n\n\/\/ RICHTIG: HMAC-SHA-256\nconst safeHmac = crypto.createHmac('sha256', secret)\n  .update(message)\n  .digest('hex');\n\n\/\/ SHA3-256: von Natur aus sicher ohne HMAC-Wrapper\nconst sha3Hash = crypto.createHash('sha3-256')\n  .update(secret + message)\n  .digest('hex');<\/code><\/pre>\n\n\n\n
In der Praxis l\u00f6st 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\u00fcr Nachrichtenauthentifizierung mit SHA-256. Wer SHA-3 ausschlie\u00dflich wegen der Length-Extension-Immunit\u00e4t bevorzugt, l\u00f6st ein Problem, das HMAC bereits adressiert.<\/p>\n\n\n\n
Sicherheitsanalyse 2026: Kryptographische St\u00e4rken und Grenzen<\/h2>\n\n\n\n
Beide Algorithmen gelten 2026 als kryptographisch sicher. F\u00fcr 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 \u00fcber marginale theoretische Verbesserungen bei reduzierten Rundenversionen hinausgehen.<\/p>\n\n\n\n
F\u00fcr SHA-3 gilt Entsprechendes: Die Keccak-f[1600]-Permutation wurde im Rahmen des NIST-Wettbewerbs f\u00fcnf Jahre intensiv analysiert. Der strukturell andere Ansatz der Sponge-Funktion bietet algorithmische Diversit\u00e4t<\/strong>, ein Sicherheitsprinzip, das in kryptographischen Systemen zunehmend gesch\u00e4tzt wird. Wenn eine zuk\u00fcnftige strukturelle Schw\u00e4che in der Merkle-Damgard-Konstruktion gefunden wird (analog zu dem, was 2005 mit SHA-1 begann), w\u00fcrde SHA-3 als Fallback bereitstehen.<\/p>\n\n\n\n
Ein praktisches Sicherheitsproblem betrifft Anwendungen, die SHA-256 direkt f\u00fcr Schl\u00fcsselableitung nutzen: SHA-256 ist kein KDF (Key Derivation Function). F\u00fcr Passwort-Hashing sollte keiner der beiden Algorithmen direkt verwendet werden. Argon2id (OWASP-Empfehlung 2026), bcrypt oder scrypt sind die richtigen Werkzeuge f\u00fcr diesen Use Case, da sie Memory-Hardness bieten und damit Brute-Force-Angriffe erheblich verteuern.<\/p>\n\n\n\n
Eine Gemeinsamkeit beider Algorithmen: Sie sind deterministisch<\/strong>, also produzieren f\u00fcr dieselbe Eingabe immer denselben Output. Das ist f\u00fcr Integrit\u00e4tspr\u00fcfungen erw\u00fcnscht, f\u00fcr Passwort-Speicherung ohne Salt aber gef\u00e4hrlich, weil Rainbow-Table-Angriffe m\u00f6glich werden. Argon2id und bcrypt l\u00f6sen dieses Problem durch eingebettetes Salt.<\/p>\n\n\n\n
Realer Einsatz 2026: Wer nutzt SHA-256, wer SHA-3?<\/h2>\n\n\n\n
Die Adoptionskurven der beiden Algorithmen verlaufen sehr unterschiedlich. SHA-256 ist seit \u00fcber einem Jahrzehnt fest in globale Infrastruktur einbetoniert. SHA-3 findet langsam seinen Weg in Systeme, die algorithmische Diversit\u00e4t oder spezifische Sponge-Eigenschaften ben\u00f6tigen.<\/p>\n\n\n\n
System \/ Protokoll<\/th>SHA-256<\/th>SHA-3 \/ Keccak<\/th>Hinweis<\/th><\/tr><\/thead>
Bitcoin (Proof of Work)<\/td>SHA-256d (doppelt)<\/td>nein<\/td>ASIC-Hardware speziell f\u00fcr SHA-256 gebaut<\/td><\/tr>
Ethereum<\/td>ja (teils)<\/td>Keccak-256 (Vorstandard)<\/td>Keccak-256 ist NICHT identisch mit SHA3-256<\/td><\/tr>
TLS 1.3<\/td>Standard (HMAC)<\/td>SHAKE256 (PQC-Erweiterungen)<\/td>SHA-256 bleibt dominant<\/td><\/tr>
Git<\/td>SHA-256 (ab 2.29)<\/td>nein<\/td>Migration von SHA-1 auf SHA-256, nicht SHA-3<\/td><\/tr>
X.509-Zertifikate<\/td>Standard<\/td>vereinzelt<\/td>CA\/Browser Forum empfiehlt SHA-256<\/td><\/tr>
NIST PQC (SLH-DSA, FIPS 205)<\/td>ja<\/td>SHAKE256 (gleichwertig)<\/td>SHA-3 erstmals Kernbestandteil eines NIST-Standards<\/td><\/tr>
CRYSTALS-Kyber (FIPS 203)<\/td>nein<\/td>SHAKE128 \/ SHAKE256<\/td>Post-Quanten-KEM nutzt ausschlie\u00dflich SHA-3<\/td><\/tr>
IPFS (ab v0.10)<\/td>SHA-256 (Standard)<\/td>SHA3-256 (optional)<\/td>Multihash-Protokoll unterst\u00fctzt beides<\/td><\/tr>
OpenSSL 3.x<\/td>Standard<\/td>SHA3-256, SHA3-512, SHAKE<\/td>Verf\u00fcgbar seit OpenSSL 1.1.0 (2016)<\/td><\/tr>
Node.js crypto<\/td>Standard<\/td>sha3-256, sha3-512<\/td>\u00dcber OpenSSL-Backend verf\u00fcgbar<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Ein wichtiges Detail zu Ethereum: Ethereum verwendet Keccak-256, nicht SHA3-256.<\/strong> Keccak-256 ist der Algorithmus, der den NIST-Wettbewerb 2012 gewann. NIST \u00e4nderte jedoch vor der Standardisierung 2015 einige Padding-Konstanten. Das Ergebnis sind zwei leicht unterschiedliche Algorithmen. Wer SHA3-256 in OpenSSL berechnet, erh\u00e4lt andere Ergebnisse als die Ethereum-Blockchain. Das ist eines der h\u00e4ufigsten Missverst\u00e4ndnisse bei SHA-3-Deployments und kann zu kritischen Bugs in Smart-Contract-Signatursystemen f\u00fchren. Immer explizit Keccak-256-Bibliotheken f\u00fcr Ethereum-Kompatibilit\u00e4t verwenden.<\/p>\n\n\n\n
Fireship, ThePrimeagen und MKBHD: Wie Content-Creator SHA-3 einordnen<\/h3>\n\n\n\n
In der Entwickler-Community hat SHA-3 eine spezifische Wahrnehmung. Fireship<\/strong> behandelt SHA-3 in seiner Kryptographie-Reihe als den strukturell \u00fcberlegenen Algorithmus und stellt die Sponge-Konstruktion als elegantere L\u00f6sung dar, empfiehlt aber f\u00fcr neue Web-Projekte SHA-256 mit HMAC wegen der breiteren Unterst\u00fctzung. ThePrimeagen<\/strong> sieht die Performance-Diskussion pragmatisch: F\u00fcr 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\u00e4nge vor allem von den tats\u00e4chlichen Hash-Durchsatzanforderungen ab. MKBHD<\/strong> thematisiert Hash-Algorithmen aus Verbraucher- und Privacy-Perspektive, wo SHA-256 in Form von TLS-Zertifikaten und App-Store-Signaturen allgegenw\u00e4rtig ist, SHA-3 dagegen f\u00fcr Endnutzer praktisch unsichtbar bleibt.<\/p>\n\n\n\n
Post-Quanten-Kryptographie: SHA-256 und SHA-3 im Quantenzeitalter<\/h2>\n\n\n\n
Quantencomputer ver\u00e4ndern das Sicherheitsbild f\u00fcr Hash-Funktionen anders als f\u00fcr Public-Key-Kryptographie. RSA und klassische elliptische Kurven werden durch den Shor-Algorithmus auf einem ausreichend gro\u00dfen 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\u00f6sen, also nur quadratisch beschleunigen statt exponentiell.<\/p>\n\n\n\n
F\u00fcr SHA-256 bedeutet das: Ein Quantencomputer k\u00f6nnte einen Preimage-Angriff in circa 2^128 Quanten-Operationen durchf\u00fchren, anstatt 2^256 klassisch. 128-Bit-Sicherheit gegen Quantenangriffe gilt 2026 als ausreichend f\u00fcr alle praktischen Zwecke<\/strong>. F\u00fcr h\u00f6here Post-Quanten-Sicherheit bietet SHA3-512 mit 2^256 Quanten-Operationen f\u00fcr Preimage-Angriffe einen deutlich gr\u00f6\u00dferen Sicherheitspuffer.<\/p>\n\n\n\n
NIST hat diesen Aspekt in seine neuen Post-Quanten-Kryptographie-Standards einbezogen. FIPS 205 (SLH-DSA)<\/strong>, das 2024 verabschiedete Post-Quanten-Signaturverfahren, erlaubt SHAKE256 als gleichwertige Alternative zu SHA-256 in allen Sicherheitsstufen. FIPS 203 (CRYSTALS-Kyber \/ ML-KEM)<\/strong> und FIPS 204 (CRYSTALS-Dilithium \/ ML-DSA)<\/strong> nutzen SHAKE128 und SHAKE256 als einzige Hash-Primitive. Das ist ein unmissverst\u00e4ndliches Signal: NIST sieht SHA-3\/SHAKE als zentralen Baustein der post-quanten-sicheren Kryptographie-Infrastruktur.<\/p>\n\n\n\n
Die Crypto-Community diskutiert zunehmend algorithmische Diversit\u00e4t als Hedging-Strategie. Wenn zuk\u00fcnftige Quantenalgorithmen oder klassische Kryptoanalyse SHA-256 schw\u00e4chen (theoretisch, aber nicht vollst\u00e4ndig auszuschlie\u00dfen), bietet SHA-3 als strukturell anderer Algorithmus eine sofort einsatzbereite Alternative. Systeme, die heute beide Algorithmen unterst\u00fctzen, sind in solchen Migrationsszenarien deutlich agiler.<\/p>\n\n\n\n
Hardware-Beschleunigung und IoT: Wann SHA-3 zum Engpass wird<\/h2>\n\n\n\n
Der Performance-Vorteil von SHA-256 basiert fast vollst\u00e4ndig 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\u00f6her).<\/p>\n\n\n\n
SHA-3 hat keine vergleichbare Breiten-Beschleunigung in Commodity-Hardware. Spezialisierte Keccak-Prozessoren (etwa in bestimmten Smartcard-Chips oder FPGA-Designs f\u00fcr Post-Quanten-Kryptographie) erreichen 2 bis 3 GB\/s. Aber diese Hardware ist nicht in Standard-Server-CPUs integriert. F\u00fcr IoT-Ger\u00e4te mit ARM Cortex-M4 (h\u00e4ufig in industriellen Sensoren, Medizinanwendungen, Smart-Home-Controllern) ist SHA3-256 mit 2,2 bis 2,8 ms pro 1 KB sp\u00fcrbar langsamer als SHA-256 mit 1,5 bis 2,0 ms.<\/strong><\/p>\n\n\n\n
In batteriebetriebenen IoT-Ger\u00e4ten ist Energieverbrauch kritischer als Latenz. Jede Hash-Berechnung kostet Joule. Ein 20-prozentiger Performance-Unterschied \u00fcbersetzt sich direkt in 20 Prozent mehr Energieverbrauch f\u00fcr Hash-intensive Operationen. \u00dcber die Lebenszeit eines Ger\u00e4ts mit tausenden t\u00e4glichen Hash-Operationen summiert sich dieser Unterschied auf messbar k\u00fcrzere Batterielaufzeiten.<\/p>\n\n\n\n
Ausnahmen gibt es bei speziell konzipierten Chips: Bestimmte Post-Quanten-Kryptographie-Prozessoren, die f\u00fcr zuk\u00fcnftige 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.<\/p>\n\n\n\n
Library-Support: SHA-256 und SHA-3 in Node.js, Python, Go und Java<\/h2>\n\n\n\n
Die Entwicklerwerkzeuge f\u00fcr SHA-256 und SHA-3 unterscheiden sich erheblich in Reife und Verf\u00fcgbarkeit. SHA-256 ist in jeder Kryptographie-Bibliothek seit \u00fcber einem Jahrzehnt stable. SHA-3 ist seit OpenSSL 1.1.0 (September 2016) verf\u00fcgbar, aber die Qualit\u00e4t der Implementierungen variiert st\u00e4rker zwischen Plattformen.<\/p>\n\n\n\n
\/\/ Node.js: SHA-256 vs SHA3-256 Vergleich\nconst crypto = require('crypto');\n\nconst data = Buffer.alloc(1024 * 1024, 'x'); \/\/ 1 MB Testdaten\n\n\/\/ SHA-256 (mit SHA-NI: ca. 20-30 ms f\u00fcr 100 Iterationen)\nconsole.time('sha256-100x');\nfor (let i = 0; i < 100; i++) {\n  crypto.createHash('sha256').update(data).digest('hex');\n}\nconsole.timeEnd('sha256-100x');\n\n\/\/ SHA3-256 (ca. 80-150 ms f\u00fcr 100 Iterationen)\nconsole.time('sha3-256-100x');\nfor (let i = 0; i < 100; i++) {\n  crypto.createHash('sha3-256').update(data).digest('hex');\n}\nconsole.timeEnd('sha3-256-100x');\n\n\/\/ HMAC-SHA-256 fuer sichere API-Authentifizierung\nconst key = crypto.randomBytes(32);\nconst token = crypto.createHmac('sha256', key)\n  .update('user_id=42&action=delete')\n  .digest('hex');\n\n\/\/ SHA3-256 fuer neue Post-Quanten-Projekte\nconst pqHash = crypto.createHash('sha3-256')\n  .update('document_content_here')\n  .digest('hex');<\/code><\/pre>\n\n\n\n
In OpenSSL 3.x<\/strong> (Standard auf allen modernen Linux-Distributionen) sind SHA-256 und SHA3-256 beide \u00fcber den Standard-Provider verf\u00fcgbar. SHA-256 profitiert automatisch von SHA-NI, sofern die CPU es unterst\u00fctzt. In Go<\/strong> liegen beide Algorithmen in der Standardbibliothek: crypto\/sha256<\/code> seit Go 1.1, golang.org\/x\/crypto\/sha3<\/code> als offizielle Erweiterung seit Go 1.17.<\/p>\n\n\n\n
Python<\/strong>-Entwickler greifen \u00fcber hashlib<\/code> auf beide zu: hashlib.sha256()<\/code> ist universell verf\u00fcgbar, hashlib.sha3_256()<\/code> seit Python 3.6. F\u00fcr Rust<\/strong> bietet die sha2<\/code>-Crate SHA-256 mit Backend-Beschleunigung, die sha3<\/code>-Crate SHA-3. In Java<\/strong> ist SHA-256 im JDK enthalten, SHA3-256 und SHA3-512 seit Java 9 im Security-Provider. PHP<\/strong>: hash('sha256', ...)<\/code> seit PHP 5, hash('sha3-256', ...)<\/code> seit PHP 7.1.<\/p>\n\n\n\n
SHAKE128 und SHAKE256: Variable Ausgabel\u00e4ngen als Alleinstellungsmerkmal<\/h2>\n\n\n\n
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)<\/strong>: Sie erzeugen Ausgaben beliebiger L\u00e4nge, nicht nur 256 oder 512 Bit. SHAKE128 bietet 128-Bit-Sicherheitsst\u00e4rke, SHAKE256 bietet 256-Bit-Sicherheitsst\u00e4rke, unabh\u00e4ngig von der gew\u00e4hlten Ausgabel\u00e4nge.<\/p>\n\n\n\n
Praktische Anwendungen f\u00fcr XOFs sind vielf\u00e4ltig. F\u00fcr Key Derivation<\/strong> ersetzt SHAKE256 komplexere HKDF-Konstruktionen. Als Stream Cipher<\/strong>-Basis erzeugt SHAKE128 pseudozuf\u00e4llige Bitstr\u00f6me mit 128-Bit-Sicherheit. Als Kern von NIST Post-Quanten-Standards<\/strong> nutzt CRYSTALS-Kyber (FIPS 203) SHAKE128 und SHAKE256 f\u00fcr Key-Generation, Encapsulation und Signing. KMAC (Keccak-basierter MAC, NIST SP 800-185) basiert auf SHAKE und bietet einen saubereren MAC-Mechanismus als HMAC.<\/p>\n\n\n\n
Ein konkretes Deployment-Beispiel: Das NIST CSRC Hash-Functions-Projekt<\/a> listet SHAKE128 und SHAKE256 als approved Functions f\u00fcr alle PQC-relevanten Anwendungen. Mit der Verabschiedung von FIPS 203\/204\/205 im Jahr 2024 sind SHAKE-Funktionen de facto verpflichtend f\u00fcr jeden, der Post-Quanten-sichere Kryptographie nach NIST-Standard implementiert.<\/p>\n\n\n\n
Migrationsleitfaden: Von SHA-256 zu SHA-3 in 6 Schritten<\/h2>\n\n\n\n
Eine Migration von SHA-256 zu SHA-3 erfordert sorgf\u00e4ltige Planung, da Hash-Werte nicht kompatibel sind. H_SHA256(m) \u2260 H_SHA3-256(m) f\u00fcr dieselbe Nachricht m, auch wenn die Ausgabegr\u00f6\u00dfe identisch ist (je 32 Bytes). Eine nahtlose Migration ohne Downtime ist mit dem folgenden Ansatz m\u00f6glich:<\/p>\n\n\n\n
Schritt 1: Inventar erstellen.<\/strong> Identifiziere alle Stellen im Code, die SHA-256 f\u00fcr 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.<\/p>\n\n\n\n
Schritt 2: Datenbankschema pr\u00fcfen.<\/strong> SHA-256 und SHA3-256 erzeugen beide 32-Byte-Ausgaben. Bin\u00e4re Spalten (BINARY(32) oder BYTEA) und Hex-Strings (VARCHAR(64)) bleiben kompatibel. Das Schema muss nicht ge\u00e4ndert werden. Aber bestehende Hash-Werte m\u00fcssen neu berechnet werden, da alte und neue Hashes nicht verglichen werden k\u00f6nnen.<\/p>\n\n\n\n
Schritt 3: Versionierungsfeld einf\u00fchren.<\/strong> F\u00fcge ein Feld ein (z.B. hash_algo: 'sha256' | 'sha3-256'<\/code>) in Datenstrukturen, die persistierte Hashes speichern. Damit k\u00f6nnen alte SHA-256-Hashes weiterhin validiert und neue SHA3-256-Hashes parallel erzeugt werden.<\/p>\n\n\n\n
Schritt 4: Duales Hashing in der \u00dcbergangsphase.<\/strong> Neue Eintr\u00e4ge erhalten SHA3-256-Hashes. Alte SHA-256-Hashes werden bei n\u00e4chstem Zugriff automatisch auf SHA3-256 migriert (Lazy Migration). Dieses Muster wird analog f\u00fcr Passwort-Hashing-Migrationen seit Jahren erfolgreich eingesetzt.<\/p>\n\n\n\n
Schritt 5: Ethereum-Spezialfall beachten.<\/strong> Falls dein System Ethereum-Adressen oder Transaktionshashes validiert, verwende niemals sha3-256<\/code> aus OpenSSL\/Node.js, sondern eine explizite Keccak-256-Bibliothek (z.B. ethereum-cryptography<\/code> in JavaScript). Der Unterschied liegt im Padding-Byte: SHA-3 nutzt 0x06, das originale Keccak nutzt 0x01. Dieser Fehler f\u00fchrt zu Hashes, die von der Ethereum-Node abgelehnt werden.<\/p>\n\n\n\n
Schritt 6: Compliance-Pr\u00fcfung.<\/strong> FIPS 140-3 zertifizierte Module unterst\u00fctzen SHA-3. PCI DSS 4.0 akzeptiert SHA3-256 f\u00fcr Hash-Operationen. F\u00fcr Finanzinstitute unter FINMA- oder FMA-Aufsicht (\u00d6sterreich) gilt SHA-3 als NIST-konformer Standard. Eine explizite Abstimmung mit dem zust\u00e4ndigen Compliance-Team ist trotzdem empfehlenswert, bevor neue Hash-Algorithmen in regulierten Systemen produktiv gehen.<\/p>\n\n\n\n
Use-Case-Empfehlungen: Wann welcher Algorithmus?<\/h2>\n\n\n\n
Die richtige Algorithmuswahl h\u00e4ngt vom Einsatzkontext ab. Hier sind konkrete Empfehlungen f\u00fcr die h\u00e4ufigsten Szenarien:<\/p>\n\n\n\n
Use Case 1: Web-API-Authentifizierung (HMAC).<\/strong> Empfehlung: HMAC-SHA-256. SHA-256 mit HMAC ist gegen Length-Extension-Angriffe gesch\u00fctzt, nativ in allen Bibliotheken unterst\u00fctzt, und 3,7-mal schneller als SHA-3 auf Serverhardware. Der Performance-Vorteil reduziert CPU-Last unter hoher Last. SHA-3 w\u00e4re hier \u00dcberengineering ohne praktischen Sicherheitsvorteil gegen\u00fcber HMAC-SHA-256.<\/p>\n\n\n\n
Use Case 2: Digitale Signaturen f\u00fcr Langzeitarchivierung.<\/strong> Empfehlung: SHA3-256 oder SHA-256 mit Migrationsplan. F\u00fcr Dokumente mit 10- bis 20-j\u00e4hrigem Archivierungshorizont ist algorithmische Diversit\u00e4t ein Argument. Wenn die Anwendung bereits NIST-PQC-Signaturen (SLH-DSA, ML-DSA) integriert, ist SHA-3\/SHAKE256 bereits im Stack, Konsistenz spricht f\u00fcr SHA-3.<\/p>\n\n\n\n
Use Case 3: Blockchain und Merkle-Trees.<\/strong> Empfehlung: SHA-256 f\u00fcr Bitcoin-kompatible Systeme, SHA3-256 f\u00fcr neue Protokolle ohne Legacy-Bindung. Bitcoin-ASICs sind auf SHA-256 optimiert und nicht austauschbar. Neue Blockchain-Protokolle ohne ASIC-Bindung k\u00f6nnen SHA3-256 w\u00e4hlen, wenn algorithmische Diversit\u00e4t ein Design-Ziel ist. Ethereum-kompatible Systeme m\u00fcssen zwingend Keccak-256 (nicht SHA3-256) verwenden.<\/p>\n\n\n\n
Use Case 4: Passwort-Hashing.<\/strong> Empfehlung: Keiner der beiden Algorithmen direkt.<\/strong> Weder SHA-256 noch SHA-3 eignen sich f\u00fcr Passwort-Hashing. Argon2id (OWASP-Empfehlung 2026), bcrypt oder scrypt sind die richtigen Werkzeuge. Diese Algorithmen bieten Memory-Hardness und Ressourcenbeschr\u00e4nkung f\u00fcr Angreifer, was schnelle Hash-Funktionen wie SHA-256 und SHA-3 grunds\u00e4tzlich nicht leisten.<\/p>\n\n\n\n
Use Case 5: Integrit\u00e4tspr\u00fcfung von Softwaredistributions.<\/strong> Empfehlung: SHA-256 f\u00fcr maximale Kompatibilit\u00e4t, SHA3-256 f\u00fcr neue Projekte mit Post-Quanten-Sicherheitsziel. Package-Manager (apt, npm, pip) nutzen SHA-256 universell. Eine SHA3-256-Pr\u00fcfsumme w\u00e4re f\u00fcr End-User-Tools eine ungew\u00f6hnliche Wahl ohne praktischen Vorteil, erh\u00f6ht aber die algorithmische Diversit\u00e4t des Softwareangebots.<\/p>\n\n\n\n
Use Case 6: Post-Quanten-sichere TLS-Infrastruktur.<\/strong> Empfehlung: SHAKE256 f\u00fcr 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.<\/p>\n\n\n\n
Verf\u00fcgbarkeit und Kosten im \u00dcberblick<\/h2>\n\n\n\n
Faktor<\/th>SHA-256<\/th>SHA3-256<\/th>SHA3-512<\/th><\/tr><\/thead>
Lizenz<\/td>Public Domain (NIST)<\/td>Public Domain (NIST)<\/td>Public Domain (NIST)<\/td><\/tr>
OpenSSL<\/td>seit 0.9.x (2000)<\/td>seit 1.1.0 (2016)<\/td>seit 1.1.0 (2016)<\/td><\/tr>
Node.js crypto<\/td>sha256 (standard)<\/td>sha3-256<\/td>sha3-512<\/td><\/tr>
Python hashlib<\/td>sha256 (standard)<\/td>sha3_256 (ab 3.6)<\/td>sha3_512 (ab 3.6)<\/td><\/tr>
Go stdlib<\/td>crypto\/sha256<\/td>golang.org\/x\/crypto\/sha3<\/td>golang.org\/x\/crypto\/sha3<\/td><\/tr>
Java JDK<\/td>seit JDK 1.4<\/td>seit Java 9 (2017)<\/td>seit Java 9 (2017)<\/td><\/tr>
FIPS 140-3 Zertifizierung<\/td>alle Major-Provider<\/td>alle Major-Provider<\/td>alle Major-Provider<\/td><\/tr>
NIST-PQC-Standards<\/td>FIPS 205 (optional)<\/td>FIPS 203, 204, 205<\/td>FIPS 205 (optional)<\/td><\/tr>
Kosten<\/td>kostenlos<\/td>kostenlos<\/td>kostenlos<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Beide Algorithmen sind kostenlos, patentfrei und NIST-standardisiert. Der einzige reale Kostenfaktor bei SHA-3 ist der h\u00f6here CPU-Aufwand in Software-Only-Implementierungen. Bei 3,7-mal h\u00f6herem CPU-Bedarf f\u00fcr SHA3-256 gegen\u00fcber 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.<\/p>\n\n\n\n
Experteneinsch\u00e4tzungen: Was Kryptographen empfehlen<\/h2>\n\n\n\n
Die kryptographische Community ist sich 2026 einig: SHA-256 bleibt f\u00fcr die \u00fcberwiegende Mehrheit der Anwendungen die richtige Wahl, SHA-3 gewinnt in spezifischen Kontexten an Bedeutung.<\/p>\n\n\n\n
Bruce Schneier<\/strong>, einer der einflussreichsten Kryptographen und langj\u00e4hriger Sicherheitsanalyst, betont kryptographische Agilit\u00e4t als Kernprinzip: Systeme sollten so gebaut sein, dass Hash-Algorithmen ausgetauscht werden k\u00f6nnen, ohne die Architektur zu \u00fcberarbeiten. Seine Kernposition zu SHA-256: Es bleibt f\u00fcr praktische Zwecke sicher und wird es auf absehbare Zeit bleiben. SHA-3 ist wertvoll als algorithmische Alternative, nicht als unmittelbarer Ersatz.<\/p>\n\n\n\n
Dan Boneh<\/strong> (Stanford University), bekannt durch seine breite Kryptographie-Kursreihe auf Coursera, betont SHA-3s Sponge-Konstruktion als didaktisch \u00fcberlegenes Modell. Er erkl\u00e4rt die strukturellen Unterschiede zwischen Merkle-Damgard und Sponge in seinem Kurs ausf\u00fchrlich und empfiehlt f\u00fcr produktive Systeme pragmatisch HMAC-SHA-256, solange keine spezifischen Anforderungen SHA-3 verlangen.<\/p>\n\n\n\n
Bart Preneel<\/strong> (KU Leuven, Mitbegr\u00fcnder des RIPE-Projekts, einer der f\u00fchrenden Kryptographen Europas) sch\u00e4tzt SHA-3 f\u00fcr seinen innovativen konstruktiven Ansatz, sieht aber die fehlende Hardware-Beschleunigung in Commodity-Chips als prim\u00e4res Adoptionshindernis. Seine Empfehlung: SHA-3 f\u00fcr langlebige kryptographische Systeme und Post-Quanten-Kontext, SHA-256 f\u00fcr bestehende und Performance-kritische Infrastruktur.<\/p>\n\n\n\n
Das NIST<\/strong> selbst sendet mit FIPS 203\/204\/205 ein klares Signal: SHAKE256 ist ein First-Class-B\u00fcrger in der Post-Quanten-Kryptographie-Landschaft. Wer heute in neue kryptographische Infrastruktur mit einem 10- bis 20-j\u00e4hrigen Horizont investiert, sollte SHA-3-Kompatibilit\u00e4t von Anfang an einplanen.<\/p>\n\n\n\n
Fazit und Urteil: SHA-256 gewinnt heute, SHA-3 gewinnt langfristig<\/h2>\n\n\n\n
Das Urteil l\u00e4sst sich klar formulieren: SHA-256 gewinnt 2026 im Alltag. SHA-3 gewinnt auf lange Sicht und in Post-Quanten-Kontexten.<\/strong><\/p>\n\n\n\n
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\u00fctzt. F\u00fcr bestehende Systeme, Performance-kritische Anwendungen und jede Infrastruktur mit harter Kompatibilit\u00e4tsanforderung ist SHA-256 die korrekte Wahl.<\/p>\n\n\n\n
SHA-3 gewinnt in drei klaren Bereichen: Post-Quanten-Kryptographie (SHAKE256 ist Kernkomponente in FIPS 203\/204\/205), algorithmische Diversit\u00e4t als Backup-Strategie gegen unbekannte zuk\u00fcnftige Angriffe auf die Merkle-Damgard-Konstruktion, und Anwendungen, die variable Ausgabel\u00e4ngen (XOF) ohne zus\u00e4tzliche KDF-Konstruktionen ben\u00f6tigen.<\/p>\n\n\n\n
Die gute Nachricht: Eine Entweder-Oder-Entscheidung ist meist nicht n\u00f6tig. Gut gestaltete kryptographische Systeme abstrahieren den Hash-Algorithmus hinter einer konfigurierbaren Schicht und k\u00f6nnen bei Bedarf von SHA-256 auf SHA-3 wechseln. Kryptographische Agilit\u00e4t, nicht Algorithmus-Loyalit\u00e4t, ist die richtige Antwort f\u00fcr 2026 und dar\u00fcber hinaus.<\/p>\n\n\n\n
Verwandte Artikel auf shattered.io<\/h2>\n\n\n\n
Weiterf\u00fchrende Lekt\u00fcre<\/h3>\n\n\n\n