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 heisst Length Extension gegen Merkle-Damgård, und Bitcoins Double-SHA256 wurde als Abwehr sechs Jahre vor dem Genesis-Block veröffentlicht. Ausserhalb Bitcoins ist HMAC (RFC 2104) der Fix. Grovers Algorithmus reduziert SHA-256 von 2²⁵⁶ auf 2¹²⁸. Immer noch unendlich.

Was "SHA-256 wurde gebrochen" wirklich bedeutet

Alle paar Monate erklärt eine Schlagzeile SHA-256 für gebrochen. Die Foren kochen. Ein r/cryptography-Thread (15jpuzg) und eine Hacker-News-Diskussion (36058754) kreisen um dasselbe Missverständnis. Ein spezifischer Angriff existiert in einem spezifischen Kontext. Der Rest des Internets liest "Bitcoin ist in Gefahr".

Ist er nicht. Ich arbeite im Krypto-Selbstverwahrungs-Bereich und jedes Mal, wenn die Schlagzeile auftaucht, leitet mir jemand den Thread weiter und fragt, ob sein Cold Storage gefährdet sei. Ist es nicht. Sorgen sollte man sich um die Annahme machen, wie SHA-256 überall sonst im Internet verwendet wird.

Der Angriff heisst Length-Extension-Angriff. Er ist real, auf einem Laptop in unter zehn Minuten reproduzierbar, und Bitcoin besiegt ihn durch Design. Jede andere "SHA-256 gebrochen"-Behauptung 2026 reduziert sich auf eines von drei Dingen: Length Extension (das Bitcoin handhabt), Partial-Round-Kryptanalyse ohne praktischen Exploit gegen volles SHA-256, oder SHA-256 missbraucht für Passwortspeicherung. Konstruktionsfehler, nicht Algorithmusfehler.

Der Durchlauf unten zeigt, was Length Extension tut, warum SHA256d sie gegen Bitcoins Hash-Kette unmöglich macht, wie die Abhilfe ausserhalb Bitcoins aussieht (HMAC), und den einen Fall, in dem SHA-256 wirklich versagt: Passwörter. Am Ende reproduzierst du den Angriff gegen einen anfälligen Demo-Server mit einem Python-Tool und siehst denselben Angriff scheitern, sobald der Server zu Bitcoins Konstruktion wechselt.

Wie Merkle-Damgård funktioniert

SHA-256 gehört zur SHA-2-Familie. Alle teilen dasselbe Design: die Merkle-Damgård-Konstruktion. Eine Minute reicht zum Verständnis, und diese Minute macht Length Extension offensichtlich.

Ein Merkle-Damgård-Hash zerhackt die Nachricht in Blöcke fester Grösse (64 Bytes bei SHA-256). Er startet mit einem festen Anfangszustand (IV) und führt 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 Digest aus.

Der letzte Satz ist das Problem. Der Digest IST der interne Zustand der Kompressionsfunktion am Ende der Berechnung. Wenn du Hash(message) kennst, kennst du den Zustand der Kompressionsfunktion nach Verarbeitung von message. Du rechnest von dort weiter.

Length Extension nutzt genau das. Gegeben Hash(secret || message) hältst du den Zustand nach secret || message. Du setzt fort, hängst beliebige Zusatzdaten an, erzeugst einen gültigen Hash. secret lernst du nie.

SHA-3 (Keccak) funktioniert anders. Seine Sponge Construction gibt nur eine Abschneidung des Zustands aus, nicht den Zustand selbst. SHA-512/256, BLAKE2 und BLAKE3 verwenden ähnliche Abschneidetricks. Alle durch Design immun. SHA-256, auf dem Bitcoin läuft, nicht.

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

Wie Length Extension funktioniert

Das kanonische Beispiel aus dem Wikipedia-Eintrag zu Length-Extension-Angriffen, seit 2009 in jedem Krypto-Lehrbuch reproduziert:

Ein Webserver signiert API-Anfragen mit SHA-256(secret || params). Die Signatur reist 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. Für jeden, der die Merkle-Damgård-Padding-Regeln nicht im Kopf hat, sieht das in Ordnung aus. Das beschreibt die meisten Entwickler, 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 das deterministische Merkle-Damgård-Padding (RFC 6234 §4.1), das SHA-256 vor dem letzten Kompressionsschritt anhängen würde. Dann initialisiert er einen neuen SHA-256-Zustand aus sig, denn sig IST der interne Zustand nach Verarbeitung von secret || params || (auto-padding). Von dort setzt er die Berechnung fort, fügt &role=admin an und gibt den neuen Zustand als gefälschte Signatur aus.

Er 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. Die Konstruktion kommutiert mit der Erweiterung. Der Angreifer ist jetzt admin.

Der bekannteste Exploit dieses Musters ist die Flickr-API-Fälschung von 2009 durch Thai Duong und Juliano Rizzo: dieselbe Konstruktion, unbefugtes Löschen von Fotos. Die Technik ist älter (Bleichenbacher diskutierte sie in den 1990ern), aber Flickr machte sie zum Lehrplan-Standard für Penetrationstests.

Man braucht ein gültiges (params, sig)-Paar und die Byte-Länge des Geheimnisses. Das ist die ganze Angriffsfläche. SHA-256 ist algorithmisch nicht gebrochen. Der Entwickler hat die falsche Konstruktion gewählt.

Den Angriff mit hash_extender reproduzieren

Du reproduzierst den Angriff auf deinem Rechner in unter zehn Minuten. Vollständige Schritt-für-Schritt-Anleitung im HowTo-Block oben. Die Kurzversion mit Quell-Repositories:

Das Python-Werkzeug eid3t1c/Hash_Extender automatisiert die Fälschung für MD5, SHA-1, SHA-256 und SHA-512. Die ältere C-Implementierung iagox86/hash_extender (Release 2014) leistet dasselbe und wird in den meisten Tutorials seit 2014 zitiert. Beide funktionieren.

Kombiniere mit magodo/sha256-length-extension-attack-demo, einem anfälligen Flask-Server, der Query-Strings mit SHA-256(secret || params) signiert. Server starten, Token erbeuten, hash_extender ausführen, Fälschung senden. Server akzeptiert. Du bist admin auf einem Server, dessen Geheimnis du nie kanntest.

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 aus. Die Fälschung schlägt fehl. Der zweite Hash nimmt den vollständigen 256-Bit-Output als Eingabe; der Angreifer hat keinen internen Zustand zum Verlängern. Diese Einzelzeile reproduziert, was Bitcoin bei jedem Block-Hash, jeder TXID, jeder Merkle-Root tut.

Eine Rust-Referenz desselben Angriffs steht in Sylvain Kerkoeurs 2026-Writeup, nützlich für die Zustandswiederherstellung auf Byte-Ebene in einer getypten Sprache. Für die schnellste Reproduktion: die Python-Tools oben.

Ich habe das durchgespielt, als ich das erste Mal an diesem Beitrag arbeitete. Zuzusehen, wie die Fälschung gelingt und dann gegen SHA-256(SHA-256(...)) zerbricht, überzeugt mehr als jede Merkle-Damgård-Erklärung auf einer Seite. Wer kryptographische Intuition statt Vokabular will, findet hier den billigsten Angriff überhaupt.

Warum SHA256d Bitcoin gegen Length Extension immunisiert

Bitcoin berechnet SHA-256(SHA-256(x)), SHA256d, überall dort, wo ein Hash im konsenskritischen Protokoll auftritt. Block-Header für Proof-of-Work. Transaction-IDs. Merkle-Roots. Der Block-Hash, nach dem Miner suchen, muss als SHA256d unter dem Schwierigkeitsziel liegen.

Ferguson und Schneier schlugen Double-Hash in Practical Cryptography (2003) als Abwehr gegen Length Extension auf SHA-2 vor. Das Argument ist kurz: Der äussere SHA-256 läuft über den vollen 256-Bit-Output des inneren. Wer SHA256d(secret || params) kennt, hält keinen nutzbaren Zustand der äusseren Kompressionsfunktion. Den Zustand zu ermitteln heisst, den äusseren SHA-256 umzukehren: ein Preimage-Angriff bei ~2²⁵⁶ Operationen. Das ist die Garantie.

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 Start 2009. Das Whitepaper sagt nur "SHA-256". Die Kryptographie-Mailingliste schweigt zur Konstruktionswahl. Ob Satoshi SHA256d explizit gegen Length Extension wählte, ist nicht belegbar. Wir wissen: Ferguson-Schneier hatten die Konstruktion sechs Jahre zuvor publiziert, Tahoe-LAFS verwendete sie bereits für Capability-Hashes aus genau diesem Grund, und Bitcoin lief von Tag eins an mit SHA256d. Zieh deine eigenen Schlüsse. Die technische Tatsache bleibt: Bitcoins Hash-Kette ist gegen Length Extension immun, und der Angriff hinter den Schlagzeilen trifft keine Schicht des Protokolls.

HMAC, der Fix für alle anderen

Die meisten Entwickler schreiben nie SHA256d. Sie schreiben HMAC.

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 mit allen):

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 hasht 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 Hash und integriert sich sauber in KDF-Stacks. IETF-Standard seit RFC 2104 von 1997. Jede Krypto-Bibliothek behandelt HMAC-SHA256 als Primitiv.

In Produktion trifft man es am häufigsten an zwei Stellen: TLS 1.3 verwendet HMAC-SHA256 in seinem HKDF-Key-Schedule (RFC 8446 §7.1), und JWT-Tokens mit Algorithmus HS256 werden als HMAC-SHA256(secret, header.payload) signiert. AWS SigV4 und WebAuthn ziehen aus demselben Grund am gleichen Primitiv.

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

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

SHA-3 (Keccak), 2015 von NIST standardisiert (FIPS-202), basiert auf einer Sponge Construction. Durch Konstruktion gegen Length Extension immun. Kein Double-Hash nötig, kein HMAC-Wrapper nötig. SHA-3-Hashes lassen sich direkt als MAC verwenden (KMAC) und bleiben sicher.

Bitcoin läuft 2026 immer noch auf SHA-256, aus Pfadabhängigkeit, nicht aus Kryptographie. Algorithmuswechsel heisst Hard Fork. Jeder Full Node, Miner, Wallet, Block-Explorer, jedes BIP und Signaturschema berührt SHA-256. Koordinierte Migration ist technisch möglich, politisch katastrophal. Dutzende Milliarden Dollar ASIC-Hardware existieren ausschliesslich, um SHA-256 mit maximalem Durchsatz zu berechnen; ein Wechsel obsoletiert die Mining-Basis über Nacht. SHA-256 ist ausserdem schneller als SHA-3 auf modernen CPUs und drastisch schneller auf ASICs. Verifikation auf jedem Full Node profitiert davon.

Das kryptographische Argument für den Status quo ist einfacher: SHA256d löst die einzige strukturelle Schwäche, die in Bitcoins Bedrohungsmodell zählt. Kein akutes Problem, das eine Migration beheben würde. SHA-3 wäre 2009 vertretbar gewesen. 2026 überwiegen die Migrationskosten den Nutzen bei weitem.

Quantum, Grover und SHA-256

Quantencomputer brechen SHA-256 nicht.

Der relevante Quantenalgorithmus gegen eine Hash-Funktion ist Grover. Er liefert einen quadratischen Speedup bei unstrukturierter Suche. Für SHA-256 sinkt die Preimage-Resistenz von 2²⁵⁶ klassisch auf 2¹²⁸ Quanten. 2¹²⁸ bleibt effektiv unendlich, jenseits jeder Quantenhardware, die für die nächsten Jahrzehnte projiziert wird.

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

Das Quantenbild für Bitcoin 2026 im Detail (BIP-360, BIP-361, der PACTs-Migrationsrahmen) ist Thema zweier separater Beiträge. Siehe BIP-360/361: Quantenresistentes Bitcoin und Quantencomputer, Bitcoin und Googles Ankündigung 2026. Kurzfassung: SHA-256 sicher. ECDSA braucht Migration. Zeitrahmen liegen Jahrzehnte auseinander.

Harvest-Now-Decrypt-Later betrifft nur Bitcoins ECDSA-Signaturen. SHA-256 nicht. Ein 2¹²⁸-starkes Primitiv ist nicht wiederherstellbar, egal wie lange du sammelst.

Wo SHA-256 bei Passwörtern versagt

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

Length Extension spielt keine Rolle. SHA-256 ist zu schnell. Eine Consumer-GPU rechnet Milliarden SHA-256-Hashes pro Sekunde, Hashcat veröffentlicht die Benchmarks. Ein ungesalzenes Passwort unter etwa 15 zufälligen Zeichen fällt einer einzigen GPU in Stunden.

Passwortspeicherung braucht eine Hash-Funktion, die absichtlich langsam und speicherintensiv ist, damit GPUs keinen Vorteil gegenüber CPUs haben. Argon2id (RFC 9106, OWASP-empfohlen 2026), oder scrypt bzw. bcrypt im Altsystem.

Findest du 2026 SHA-256 für Passwörter in Code, ist die Lösung Migration der gesamten Nutzerbasis (typischerweise erneutes Hashing beim nächsten Login). Keine Length-Extension-Abwehr hinzufügen. Das Problem ist Brute-Force-Geschwindigkeit, Length Extension trägt nichts dazu bei.

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 ist 2026 praktisch gefährdet. Die bekannten praktischen Angriffe (Length Extension, Partial-Round-Kollisionen auf 31 von 64 Runden, GPU-Brute-Force auf kleine Eingaberäume) treffen den vollen Algorithmus in keiner Bitcoin-Rolle.

Der Vergleich ist SHA-1, durch Googles SHAttered-Kollision 2017 auf vollem Algorithmus praktisch gebrochen. SHA-256 ist nicht dort und hat kurzfristig keinen kryptanalytischen Kurs in die Richtung.

Das Urteil 2026 nach Anwendungsfall

Die Kette hält. Jede konsenskritische Verwendung von SHA-256 in Bitcoin läuft über SHA256d, oben als immun gegen Length Extension gezeigt. 2026 existiert kein praktischer Preimage-Angriff auf vollständiges SHA-256, kein praktischer Kollisionsangriff, nichts am Horizont, das nahe herankäme. Bitcoin-Mining, TXIDs, Merkle-Roots, P2PKH- und P2WPKH-Adressen, BIP-39-Ableitung über PBKDF2-HMAC-SHA512: alles sicher.

Ausserhalb Bitcoins ist SHA-256 hinter einem HMAC-Wrapper (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 Langzeit-Archivintegrität ist in Ordnung. Length Extension ist irrelevant ohne Geheimnis und MAC.

Zwei Muster scheitern 2026 trotzdem und sollten sofort weg. Selbstgebaute MACs der Form Hash(secret || message) lassen sich durch Length Extension trivial fälschen: wechsle zu HMAC. Rohes SHA-256 für Passwörter, gesalzen oder nicht, fällt einer GPU: wechsle zu Argon2id.

Beides sind Konstruktionsfehler, keine Algorithmusfehler. SHA-256 selbst erledigt seit 2001 seinen Job.

Weiterführende Lektüre

Dieser Beitrag gehört zu einer kleinen Gruppe auf www.btc2h.com über die kryptographischen Primitive, auf die Bitcoin tatsächlich angewiesen ist, und was aktuelle Forschung für jedes einzelne 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.