SHA-256 in Bitcoin mit Length Extension brechen

TL;DR

Ein funktionierender Angriff auf SHA-256 existiert. Ich habe ihn auf einer Wegwerf-VM in unter zehn Minuten reproduziert. Er berührt Bitcoin nicht. Der Angriff ist Length Extension gegen die Merkle-Damgård-Konstruktion, und Bitcoins Double-SHA256 wurde als Abwehrmassnahme sechs Jahre vor dem Genesis-Block veröffentlicht. Ausserhalb Bitcoins ist der kanonische Fix HMAC (RFC 2104). Grovers Algorithmus reduziert SHA-256 von 2²⁵⁶ auf 2¹²⁸, was immer noch effektiv unendlich ist.

Was "SHA-256 wurde gebrochen" wirklich bedeutet

Alle paar Monate erscheint eine frische Schlagzeile, die SHA-256 für gebrochen erklärt. Die Foren kochen über. Ein Reddit-Thread in r/cryptography (Thread 15jpuzg) und eine lange Hacker-News-Diskussion (Item 36058754) kreisen beide um dasselbe Missverständnis. Es gibt einen spezifischen Angriff gegen SHA-256 in einem spezifischen Kontext, und der Rest des Internets macht daraus "Bitcoin ist in Gefahr."

Das ist er nicht. Ich arbeite im Krypto-Selbstverwahrungs-Bereich und jedes Mal, wenn diese Schlagzeile auftaucht, leitet mir jemand den Thread weiter mit der Frage, ob sein Cold Storage gefährdet sei. Das Cold Storage ist nicht gefährdet. Die Annahme über die Art, wie SHA-256 überall sonst im Internet verwendet wird, ist der Teil, der Sorgen bereiten sollte.

Der Angriff heisst Length-Extension-Angriff. Er ist real. Er ist auf einem Laptop in unter zehn Minuten reproduzierbar. Bitcoin besiegt ihn durch Design. Jede andere "SHA-256 gebrochen"-Behauptung im Jahr 2026 reduziert sich entweder auf Length Extension (das Bitcoin handhabt), auf partielle Runden in akademischer Kryptanalyse (die keinen praktischen Exploit auf vollständiges SHA-256 produziert hat) oder auf einen Missbrauch von SHA-256 bei der Passwortspeicherung, was ein Design-Versagen ist, kein Algorithmus-Versagen.

Der folgende Durchlauf zeigt, was Length Extension wirklich tut, warum Bitcoins SHA256d-Konstruktion sie gegen Bitcoins Hash-Kette unmöglich macht, wie die kanonische Abhilfe in Nicht-Bitcoin-Code aussieht (HMAC), und den einen Anwendungsfall, bei dem SHA-256 tatsächlich unsicher ist: Passwortspeicherung. Am Ende reproduzierst du den Angriff gegen einen absichtlich anfälligen Demo-Server mit einem Python-Tool, und siehst dann denselben Angriff scheitern, wenn der Server zu Bitcoins Konstruktion wechselt.

Wie Merkle-Damgård funktioniert

SHA-256 gehört zur SHA-2-Familie, die alle dasselbe grundlegende Design teilen, die sogenannte Merkle-Damgård-Konstruktion. Sie zu verstehen dauert etwa eine Minute, und diese Minute macht Length Extension offensichtlich.

Ein Merkle-Damgård-Hash nimmt eine lange Nachricht und zerhackt sie in Blöcke fester Grösse (64 Bytes für SHA-256). Er beginnt mit einem festen Anfangszustand (dem IV) und führt dann für jeden Block eine Kompressionsfunktion aus, die den Block in den Zustand einmischt. Nach dem letzten Block gibt der Algorithmus den Zustand direkt als Hash-Digest aus.

Dieser letzte Satz ist das gesamte Problem. Der endgültige Digest des Hashes ist der interne Zustand der Kompressionsfunktion am Ende der Berechnung. Wenn du Hash(message) kennst, kennst du den internen Zustand der Kompressionsfunktion nachdem sie message verarbeitet hat. Du kannst von dort weiterrechnen.

Genau das nutzt Length Extension aus. Gegeben Hash(secret || message) hältst du den Zustand, bei dem die Kompressionsfunktion nach dem Verarbeiten von secret || message angelangt ist. Du setzt die Berechnung von diesem Zustand aus fort, hängst beliebige Zusatzdaten an und erzeugst einen gültigen Hash. Du erfährst secret nie.

SHA-3 (Keccak) funktioniert nicht so. Seine Sponge Construction gibt nur eine Abschneidung des internen Zustands aus, nicht den Zustand selbst. SHA-512/256, BLAKE2 und BLAKE3 verwenden ähnliche Abschneidetricks. Diese Algorithmen sind durch Design gegen Length Extension immun. SHA-256, der Algorithmus, auf dem Bitcoin läuft, ist es nicht.

Das ist die strukturelle Tatsache hinter jeder "SHA-256 ist gebrochen"-Schlagzeile. Nun der Angriff selbst im Code.

Wie Length Extension funktioniert

Das kanonische Motivationsbeispiel, verwendet im Wikipedia-Eintrag zu Length-Extension-Angriffen und in jedem Krypto-Lehrbuch seit 2009 reproduziert, sieht so aus.

Ein Webserver signiert API-Anfragen durch Berechnung von SHA-256(secret || params). Er veröffentlicht die Signatur zusammen mit der Anfrage:

GET /api?user=alice&role=user&sig=a3f1...

Der Server validiert, indem er SHA-256(secret || "user=alice&role=user") neu berechnet und mit sig vergleicht. Die Konstruktion sieht für jeden in Ordnung aus, der die Merkle-Damgård-Padding-Regeln nicht genau kennt, was auf die meisten Entwickler zutrifft, die 2026 Code ausliefern.

Der Angreifer erbeutet ein gültiges (params, sig)-Paar. Er schätzt die Byte-Länge von secret (typischerweise 16, 32 oder 64, also probiert er alle drei). Er berechnet die Merkle-Damgård-Padding-Bytes, die SHA-256 an secret || params vor dem letzten Kompressionsschritt angehängt hätte. Das Padding ist deterministisch (RFC 6234 §4.1). Dann initialisiert er einen neuen SHA-256-Zustand aus der erbeuteten sig, denn die erbeutete Signatur IST der interne Zustand der Kompressionsfunktion nach dem Verarbeiten von secret || params || (auto-padding). Von diesem Zustand aus setzt er die SHA-256-Berechnung fort, fügt &role=admin oder eine beliebige Erweiterung ein und gibt den neuen Zustand als gefälschte Signatur aus.

Der Angreifer sendet:

GET /api?user=alice&role=user[padding bytes]&role=admin&sig=<forged>

Der Server berechnet SHA-256(secret || "user=alice&role=user[padding]&role=admin") und erhält exakt die gefälschte Signatur, weil die Konstruktion mit der Erweiterung des Angreifers kommutiert. Der Angreifer ist jetzt admin.

Der bekannteste öffentliche Exploit dieses Musters ist die Flickr-API-Fälschung von 2009 durch Thai Duong und Juliano Rizzo, bei der dieselbe Konstruktion unbefugtes Löschen von Fotos über die Flickr-API ermöglichte. Die Technik ist älter (Daniel Bleichenbacher diskutierte sie in den 1990er-Jahren), aber der Flickr-Fall machte sie zum festen Bestandteil von Penetrationstest-Lehrplänen.

Man braucht ein gültiges (params, sig)-Paar und die Byte-Länge des Geheimnisses. Das ist die gesamte Angriffsfläche. SHA-256 ist in keinem algorithmischen Sinne gebrochen. Der Entwickler hat nur die falsche Konstruktion verwendet.

Den Angriff mit hash_extender reproduzieren

Du kannst den Angriff auf deinem eigenen Rechner in unter zehn Minuten reproduzieren. Die vollständige Schritt-für-Schritt-Anleitung steht im HowTo-Block am Anfang dieser Seite. Die Kurzversion mit primären Quell-Repositories.

Das Python-Angriffswerkzeug eid3t1c/Hash_Extender automatisiert die Length-Extension-Fälschung für MD5, SHA-1, SHA-256 und SHA-512. Die frühere kanonische C-Implementierung von iagox86/hash_extender (das originale Release von 2014) erledigt dieselbe Aufgabe und ist das Werkzeug, das in den meisten Length-Extension-Tutorials seit 2014 zitiert wird. Beide funktionieren.

Kombiniere es mit magodo/sha256-length-extension-attack-demo, einem absichtlich anfälligen Flask-Server, der Query-Strings mit SHA-256(secret || params) signiert. Starte den Server, erbeute ein Token, führe hash_extender aus, sende die Fälschung. Der Server akzeptiert sie. Du bist jetzt admin auf einem Webserver, dessen Geheimnis du nie erfahren hast.

Dann ändere eine Zeile des Demo-Servers. Ersetze SHA-256(secret || params) durch SHA-256(SHA-256(secret || params)) und führe den Angriff erneut durch. Die Fälschung schlägt fehl. Der zweite Hash nimmt den vollständigen 256-Bit-Output als Eingabe, und der Angreifer hat keinen internen Zustand, den er verlängern könnte. Diese einzelne Änderung reproduziert das, was Bitcoin bei jedem Block-Hash, jeder TXID, jeder Merkle-Root tut.

Eine Rust-Referenzimplementierung desselben Angriffs findet sich in Sylvain Kerkoeurs 2026-Writeup, nützlich wenn du die Zustandswiederherstellungslogik auf Byte-Ebene in einer getypten Sprache nachvollziehen möchtest. Für die schnellste Reproduktion sind die Python-Tools oben vorzuziehen.

Ich habe das von Anfang bis Ende durchgeführt, als ich das erste Mal an diesem Beitrag gearbeitet habe. Zuzusehen, wie die Fälschung gelingt, und dann zu sehen, wie sie gegen SHA-256(SHA-256(...)) scheitert, ist überzeugender als jede Erklärung von Merkle-Damgård auf der Seite. Wer kryptographische Intuition statt kryptographisches Vokabular möchte, findet hier den günstigsten Angriff, den man ausführen kann.

Warum SHA256d Bitcoin gegen Length Extension immunisiert

Bitcoin berechnet SHA-256(SHA-256(x)), genannt SHA256d, für jeden Ort, an dem ein Hash im konsenskritischen Protokoll erscheint. Block-Header, die Proof-of-Work für das Mining liefern. Transaction-IDs. Merkle-Roots, die alle Transaktionen in einem Block aggregieren. Der Block-Hash, nach dem Miner suchen, ein SHA256d, der unter dem Schwierigkeitsziel liegen muss.

Ferguson und Schneier schlugen die Double-Hash-Konstruktion in Practical Cryptography (2003) als kanonische Abwehr gegen Length-Extension-Angriffe auf SHA-2 vor. Das Argument ist kurz. Der äussere SHA-256 wird über den vollständigen 256-Bit-Output des inneren SHA-256 berechnet. Ein Angreifer, der SHA256d(secret || params) kennt, kennt den internen Zustand der äusseren Kompressionsfunktion in keiner nutzbaren Weise. Um diesen Zustand zu ermitteln, müsste er den äusseren SHA-256 umkehren, was ein Preimage-Angriff mit etwa 2²⁵⁶ Operationen ist. Das ist die Sicherheitsgarantie.

Eine viel zitierte crypto.stackexchange.com-Antwort verfolgt die Begründung über Tahoe-LAFS (das SHA256d 2006 aus genau diesem Grund übernahm) bis zu Bitcoins Einführung im Jahr 2009. Das Whitepaper sagt nur "SHA-256", und die Kryptographie-Mailingliste schweigt zur Wahl der Konstruktion. Ob Satoshi SHA256d explizit zur Abwehr von Length Extension gewählt hat, ist daher nicht belegbar. Wir wissen, dass Ferguson-Schneier die Konstruktion sechs Jahre zuvor veröffentlicht hatte, dass Tahoe-LAFS sie bereits für Dateisystem-Capability-Hashes genau aus diesem Grund verwendete, und dass Bitcoin am ersten Tag mit SHA256d ausgeliefert wurde. Zieh deine eigenen Schlüsse. Die technische Tatsache gilt so oder so: Bitcoins Hash-Kette ist gegen Length Extension immun, und der Angriff hinter den "SHA-256 ist gebrochen"-Schlagzeilen trifft keine Schicht des Bitcoin-Protokolls.

HMAC, der Fix für alle anderen

Die meisten Software-Entwickler werden SHA256d nie schreiben. Sie werden HMAC schreiben.

HMAC (RFC 2104) ist der universelle, gegen Length Extension immune Wrapper für jeden Merkle-Damgård-Hash. Gegeben eine Hash-Funktion H (SHA-256, SHA-1, MD5, HMAC funktioniert für alle), ist HMAC definiert als:

HMAC(key, message) = H( (key ⊕ opad) || H( (key ⊕ ipad) || message ) )

opad und ipad sind feste Byte-Muster (0x5c5c5c... bzw. 0x363636...). Der innere Hash absorbiert die Nachricht. Der äussere Hash hashiert den inneren Output mit einer anderen Schlüsselableitung.

Die Konstruktion ähnelt SHA256d, ist aber flexibler. HMAC nimmt einen Schlüssel als erstklassigen Parameter, unterstützt jeden zugrunde liegenden Hash und integriert sich sauber in Key-Derivation-Function-Stacks. Es ist seit RFC 2104 von 1997 der IETF-Standard, und jede kryptographische Bibliothek behandelt HMAC-SHA256 als Primitiv.

Die zwei Stellen, an denen man es in der Produktion am häufigsten antrifft, sind TLS 1.3, das HMAC-SHA256 innerhalb seines HKDF-Key-Schedule verwendet (RFC 8446 §7.1), und JWT-Tokens mit dem Algorithmus HS256, die als HMAC-SHA256(secret, header.payload) signiert werden. AWS SigV4 und WebAuthn ziehen aus demselben Grund am gleichen Primitiv.

Wenn dein Code irgendwo hash(secret + message) ausserhalb Bitcoins berechnet, ersetze es durch HMAC. Der Aufwand ist ein zusätzlicher Hash-Aufruf. Der Sicherheitsgewinn ist vollständige Immunität gegen Length Extension.

Warum Bitcoin bei SHA-256 blieb und nicht zu SHA-3 wechselte

SHA-3 (Keccak), von NIST 2015 standardisiert (FIPS-202), basiert auf einem grundlegend anderen Design, der Sponge Construction, die durch Konstruktion gegen Length Extension immun ist. Kein Double-Hash nötig. Kein HMAC-Wrapper nötig. SHA-3-Hashes können direkt als MACs verwendet werden (manchmal KMAC genannt) und bleiben sicher.

Bitcoin läuft 2026 immer noch auf SHA-256, aus Gründen, die eher Pfadabhängigkeit als kryptographische Natur sind. Ein Wechsel des Hash-Algorithmus erfordert einen Hard Fork. Jeder Full Node, jeder Miner, jedes Wallet, jeder Block-Explorer, jedes BIP, jedes Signaturschema berührt SHA-256 an irgendeiner Stelle. Eine koordinierte Migration ist technisch möglich, aber politisch katastrophal. Dutzende Milliarden Dollar an ASIC-Hardware existiert genau zum Berechnen von SHA-256 mit maximalem Durchsatz, und ein Algorithmenwechsel macht die gesamte Mining-Basis über Nacht obsolet. SHA-256 ist auch schneller als SHA-3 auf modernen CPUs und dramatisch schneller auf ASICs, was bei der Verifikation auf jedem Full Node eine Rolle spielt.

Das kryptographische Argument für den Status quo ist einfacher. SHA256d löst bereits die einzige strukturelle Schwäche von SHA-256, die in Bitcoins Bedrohungsmodell relevant ist. Es gibt kein akutes Problem, das eine Migration beheben würde. SHA-3 wäre 2009 eine vertretbare Wahl gewesen. Die Migrationskosten im Jahr 2026 überwiegen den Nutzen bei weitem.

Quantum, Grover und SHA-256

Quantencomputer brechen SHA-256 nicht.

Der relevante Quantenalgorithmus gegen eine Hash-Funktion ist Grovers Algorithmus, der einen quadratischen Geschwindigkeitsvorteil bei unstrukturierter Suche liefert. Für SHA-256 reduziert das die Preimage-Resistenz von 2²⁵⁶ klassischen Operationen auf 2¹²⁸ Quantenoperationen. 2¹²⁸ ist immer noch effektiv unendlich, weit jenseits jeder realistischen Quantenhardware, die für die nächsten Jahrzehnte projiziert wird.

Shors Algorithmus ist der, den man wirklich fürchten muss, und er berührt SHA-256 nicht. Shor liefert einen exponentiellen Geschwindigkeitsvorteil beim diskreten Logarithmusproblem, was ECDSA (Bitcoins Signaturschema) auf einem ausreichend grossen Quantencomputer in polynomieller Zeit bricht. Bitcoins Quantenrisiko liegt in den Signaturen, nicht im Hash.

Das aktuelle Quantenbild für Bitcoin 2026 im Einzelnen, einschliesslich BIP-360, BIP-361 und des PACTs-Migrationsrahmens, ist Gegenstand zweier separater Beiträge auf dieser Website. Siehe BIP-360/361: Quantenresistentes Bitcoin und Quantencomputer, Bitcoin und Googles Ankündigung 2026. Die Kurzfassung: SHA-256 ist sicher. ECDSA braucht Migration. Die Zeitrahmen für beides liegen Jahrzehnte auseinander.

Die Harvest-Now-Decrypt-Later-Bedrohung gilt nur für Bitcoins ECDSA-Signaturen. Auf SHA-256 trifft sie in keiner bedeutsamen Weise zu, weil ein 2¹²⁸-starkes Primitiv unabhängig vom Sammeln nicht wiederherstellbar ist.

Wo SHA-256 bei Passwörtern versagt

Der eine Kontext, in dem "SHA-256 ist unsicher" berechtigt ist, ist die Passwortspeicherung.

Das hat nichts mit Length Extension zu tun. SHA-256 ist zu schnell. Eine moderne Consumer-GPU berechnet Milliarden SHA-256-Hashes pro Sekunde, und Hashcat veröffentlicht die Benchmarks öffentlich. Für ein ungesalzenes, SHA-256-gehashtes Passwort unter etwa 15 zufälligen Zeichen brute-forced ein Angreifer mit einer Consumer-GPU den gesamten Raum in Stunden.

Passwortspeicherung erfordert eine Hash-Funktion, die absichtlich langsam und speicherintensiv ist, sodass eine GPU keinen Vorteil gegenüber einer CPU hat. Verwende Argon2id (RFC 9106, OWASP-empfohlen 2026), oder scrypt bzw. bcrypt bei älterem Stack.

Wenn du 2026 SHA-256 für die Passwortspeicherung in Code findest, ist die Lösung eine Migration der gesamten Nutzerbasis (typischerweise durch erneutes Hashing beim nächsten Login). Füge keine Length-Extension-Abwehrmassnahmen hinzu. Das echte Problem ist Brute-Force-Geschwindigkeit, und Length Extension hat damit nichts zu tun.

Wo SHA-256 in Bitcoin lebt

Für Bitcoin im Einzelnen erscheint SHA-256 (fast immer als SHA256d) in mehreren klar getrennten Rollen:

Jede dieser Rollen wäre ein katastrophaler Integritätsverlust, wenn SHA-256 bräche. Keine davon ist 2026 einem praktischen Risiko ausgesetzt. Die bekannten praktischen Angriffe (Length Extension, Partial-Round-Kollisionen auf 31 von 64 Runden, schnelles GPU-Brute-Force auf kleine Eingaberäume) erreichen nicht den vollständigen SHA-256-Algorithmus in einer Rolle, die in Bitcoin relevant ist.

Der relevante Vergleich ist SHA-1, das 2017 durch Googles SHAttered-Kollisionsangriff auf vollständiges SHA-1 praktisch gebrochen wurde. SHA-256 befindet sich nicht in diesem Zustand und hat keinen kurzfristigen kryptanalytischen Kurs in diese Richtung.

Das Urteil 2026 nach Anwendungsfall

Die Kette hält. Jede konsenskritische Verwendung von SHA-256 in Bitcoin läuft über SHA256d, das ich oben als gegen Length Extension immun gezeigt habe. Es gibt 2026 keinen praktischen Preimage-Angriff auf vollständiges SHA-256, keinen praktischen Kollisionsangriff, und nichts am kryptanalytischen Horizont, das auch nur nahe herankommt. Bitcoin-Mining, TXIDs, Merkle-Roots, P2PKH- und P2WPKH-Adressen, BIP-39-Seed-Ableitung über PBKDF2-HMAC-SHA512: alles sicher.

Ausserhalb Bitcoins ist SHA-256 überall, wo es hinter einem HMAC-Wrapper liegt (TLS-1.3-Record-Signing, JWT-HS256, AWS SigV4), ebenfalls sicher. Rohes SHA-256 für Content-Adressierung, als Pre-Hash für digitale Signaturen oder für die Langzeit-Archivintegritätsprüfung ist in Ordnung, weil Length Extension irrelevant ist, wenn kein Geheimnis und kein MAC im Spiel ist.

Zwei Muster scheitern 2026 immer noch und sollten sofort behoben werden. Selbstgebaute MACs in der Form Hash(secret || message) werden durch Length Extension trivial gefälscht. Wechsle zu HMAC. Rohes SHA-256 für Passwortspeicherung, gesalzen oder nicht, wird von einer einzigen GPU brute-forced, weil SHA-256 zu schnell ist. Wechsle zu Argon2id.

Beide Versagen sind Konstruktionsversagen, keine Algorithmusversagen. SHA-256 selbst erledigt seit 2001 seinen Job.

Weiterführende Lektüre

Dieser Artikel ist Teil einer kleinen Gruppe auf btc2h.com, die die kryptographischen Primitive untersucht, auf die Bitcoin tatsächlich angewiesen ist, und was aktuelle Forschung für jedes von ihnen bedeutet. Drei ergänzende Lektüren:

• BIP-360 / BIP-361: Der quantenresistente Bitcoin-Migrationsplan behandelt das quantenseitige Signaturbild, wo das echte langfristige Risiko liegt.
• Quantencomputer, Bitcoin und Googles Ankündigung 2026 ordnet den Quantenhardware-Nachrichtenzyklus 2026 ein.
• btcrecover-Tutorial 2026 zeigt, warum SHA-256s GPU-Brute-Force-Geschwindigkeit die richtige Antwort für die Wallet-Passwortwiederherstellung und die falsche Antwort für die Passwortspeicherung ist.

Primärquellenbibliographie für diesen Artikel (verifiziert zugänglich 2026-05-12, sofern nicht anders angegeben):

• Wikipedia, Length extension attack
• Wikipedia, SHA-2
• RFC 6234, US Secure Hash Algorithms (SHA-256-Padding-Spezifikation)
• RFC 2104, HMAC Keyed-Hashing for Message Authentication
• crypto.stackexchange.com Q779, Warum verwendet Bitcoin Double SHA-256?
• Reddit r/cryptography, SHA-256-Length-Extension-Thread
• Hacker News Thread 36058754
• arXiv 2406.20072, Partial-Round-SHA-256-Kryptanalyse (Aussage: Partial-Round-Ergebnisse, kein praktischer Full-Round-Angriff. Verifiziere gegen das Abstract des Papers, bevor du Zahlenwerte zitierst.)
• Kerkour, Breaking SHA-2 length extension attacks in practice with Rust
• eid3t1c/Hash_Extender (Python-Angriffswerkzeug)
• magodo/sha256-length-extension-attack-demo (anfälliger Flask-Server)
• sjlombardo length-extension gist (2012)
• Ferguson & Schneier, Practical Cryptography (2003), die kanonische SHA256d-Veröffentlichung

Disclaimer

Dieser Artikel ist Bildungsinhalt für Bitcoin-Inhaber und Entwickler. Er ist keine rechtliche, finanzielle oder kryptographisch-technische Beratung. Reale kryptographische Implementierungen erfordern ein formales Review durch qualifizierte Spezialisten. Implementiere keinen sicherheitskritischen Code aus einem Blog-Beitrag. Für Produktionssysteme, die Geheimnisse verarbeiten, verwende kampferprobte Bibliotheken (libsodium, OpenSSL, Bouncy Castle) statt eigener Primitive. Für rechtliche oder Compliance-Fragen zu kryptographischer Agilität unter FINMA, DSGVO oder NIS2 wende dich an qualifizierte Rechtsberatung.