Hash-Funktionen stecken überall in der Softwareentwicklung, auch wenn Sie es vielleicht nicht bemerken. Jedes Mal, wenn Sie eine Datei herunterladen und deren Prüfsumme überprüfen, sich auf einer Website einloggen, einen Git-Commit machen oder Bitcoin minen (okay, das Letzte vielleicht nicht), leisten Hash-Funktionen die Schwerstarbeit im Hintergrund.
Schauen wir uns an, was sie sind, wie sie sich unterscheiden und welche wann eingesetzt werden sollte.
Was ist eine Hash-Funktion?
Eine Hash-Funktion nimmt eine beliebige Eingabe — ein einzelnes Zeichen, einen Roman, eine 4-GB-Videodatei — und erzeugt eine Ausgabe fester Größe, den sogenannten „Hash" oder „Digest". Stellen Sie es sich als Fingerabdruck für Daten vor. Egal wie groß oder klein die Eingabe ist, die Ausgabe hat immer die gleiche Länge.
Das macht Hash-Funktionen besonders:
- Deterministisch: Gleiche Eingabe ergibt immer die gleiche Ausgabe.
hash("hello")liefert jedes einzelne Mal denselben Wert, auf jedem Rechner, in jeder Programmiersprache. - Einweg: Aus dem Hash kann die Eingabe nicht zurückberechnet werden. Bei einem gegebenen Hash gibt es keine Möglichkeit herauszufinden, was ihn erzeugt hat (außer durch Raten). Das macht sie nützlich für die Speicherung von Passwörtern.
- Lawineneffekt: Ändert man ein Bit der Eingabe, ändert sich die Ausgabe dramatisch. Zum Beispiel sind die SHA-256-Hashes von „hello" und „Hello" völlig unterschiedliche Zeichenketten.
- Kollisionsresistenz: Es sollte praktisch unmöglich sein, zwei verschiedene Eingaben zu finden, die denselben Hash erzeugen. Je stärker der Algorithmus, desto schwieriger sind Kollisionen zu finden.
Sehen wir es in Aktion:
Völlig unterschiedliche Ausgaben bei Eingaben, die sich nur in einem Zeichen unterscheiden — ein kleines „h" gegen ein großes „H". Das ist der Lawineneffekt in Aktion.
Wie Hash-Funktionen unter der Haube funktionieren
Die Mathematik hinter Hash-Funktionen ist komplex, aber der allgemeine Ablauf ist überschaubar. Die meisten Hash-Funktionen folgen diesen Schritten:
1. Padding: Die Eingabenachricht wird aufgefüllt, sodass ihre Länge ein Vielfaches einer festen Blockgröße wird (z. B. 512 Bit bei SHA-256). Das stellt sicher, dass der Algorithmus die Daten in gleichmäßigen Blöcken verarbeiten kann.
2. Blockteilung: Die aufgefüllte Nachricht wird in Blöcke fester Größe unterteilt.
3. Kompressionsrunden: Jeder Block wird durch mehrere Runden bitweiser Operationen verarbeitet — XOR, AND, OR, Bitverschiebungen und modulare Addition. Diese Operationen vermischen die Bits gründlich, sodass jedes Ausgangsbit von jedem Eingangsbit abhängt.
4. Verkettung: Die Ausgabe der Verarbeitung eines Blocks fließt in die Verarbeitung des nächsten Blocks ein. Deshalb pflanzt sich selbst eine winzige Änderung am Anfang der Eingabe durch jeden folgenden Block fort.
5. Endgültiger Digest: Nachdem alle Blöcke verarbeitet sind, wird der interne Zustand als endgültiger Hashwert ausgegeben.
Die entscheidende Erkenntnis ist, dass diese Operationen vorwärts leicht zu berechnen, aber praktisch unmöglich umzukehren sind. Man kann die Bits nicht „entmischen", um die ursprüngliche Eingabe wiederherzustellen.
MD5: Der pensionierte Veteran
MD5 wurde 1991 von Ronald Rivest entwickelt und erzeugt einen 128-Bit-Hash (32 Hex-Zeichen). Jahrzehntelang war es der Standard — man sah MD5-Prüfsummen neben jedem Datei-Download im Internet.
Allerdings gilt MD5 heute als kryptografisch gebrochen. Forscher haben praktische Kollisionsangriffe demonstriert — das heißt, sie können zwei verschiedene Dateien erzeugen, die denselben MD5-Hash haben. 2008 nutzten Forscher eine MD5-Kollision, um ein gefälschtes SSL-Zertifikat zu erstellen, und bewiesen damit, dass dies keine rein theoretische Schwäche war.
Noch akzeptabel für: Dateiintegritätsprüfungen (Überprüfung, ob ein Download korrekt abgeschlossen wurde), Prüfsummen zur Deduplizierung, nicht-sicherheitskritische Hashtabellen und schnelles Daten-Fingerprinting, wenn Sicherheit keine Rolle spielt.
Niemals verwenden für: Passwortspeicherung, digitale Signaturen, Sicherheitszertifikate oder alles, wo jemand absichtlich Kollisionen erzeugen könnte.
SHA-1: Ebenfalls im Ruhestand
SHA-1 wurde von der NSA entwickelt und 1995 veröffentlicht. Es erzeugt einen 160-Bit-Hash (40 Hex-Zeichen). Jahrelang war es der Standard für SSL-Zertifikate, PGP-Signaturen und Versionskontrollsysteme.
Es wurde veraltet, nachdem Google 2017 einen praktischen Kollisionsangriff demonstrierte (der berühmte SHAttered-Angriff). Sie erzeugten zwei verschiedene PDF-Dateien mit demselben SHA-1-Hash. Der Angriff erforderte 9.223.372.036.854.775.808 SHA-1-Berechnungen — enorm, aber machbar mit modernen Cloud-Computing-Ressourcen.
Git verwendet SHA-1 intern für Commit-Hashes, wechselt aber zu SHA-256. Browser und Zertifizierungsstellen akzeptieren seit Jahren keine SHA-1-Zertifikate mehr. Wenn Sie SHA-1 in irgendeiner Codebasis heute für Sicherheitszwecke sehen, sollte es markiert und migriert werden.
SHA-256 und SHA-512: Die aktuellen Standards
Diese gehören zur SHA-2-Familie, die von der NSA entwickelt und 2001 veröffentlicht wurde. Sie sind das, was Sie heute für die meisten Zwecke verwenden sollten.
- SHA-256: 256-Bit-Ausgabe (64 Hex-Zeichen). Verwendet in Bitcoin, TLS-Zertifikaten und den meisten Sicherheitsanwendungen. Die optimale Balance zwischen Sicherheit und Leistung. Bitcoins gesamtes Proof-of-Work-System basiert auf doppeltem SHA-256-Hashing.
- SHA-512: 512-Bit-Ausgabe (128 Hex-Zeichen). Größere Ausgabe bedeutet mehr Kollisionsresistenz. Interessanterweise ist SHA-512 auf 64-Bit-Prozessoren oft schneller als SHA-256, da es nativ mit 64-Bit-Wörtern arbeitet, während SHA-256 32-Bit-Wörter verwendet.
- SHA-384 und SHA-512/256: Dies sind gekürzte Varianten von SHA-512. SHA-384 liefert eine 384-Bit-Ausgabe, während SHA-512/256 eine 256-Bit-Ausgabe liefert, aber mit den Leistungsvorteilen der 64-Bit-Operationen von SHA-512.
Schnellvergleich:
SHA-3: Die nächste Generation
SHA-3 wurde 2015 nach einem öffentlichen Wettbewerb des NIST standardisiert. Im Gegensatz zu SHA-2, das eine Merkle-Damgard-Konstruktion verwendet, basiert SHA-3 auf der Keccak-Schwamm-Konstruktion — ein grundlegend anderes Design.
Warum ist das wichtig? Sollte ein mathematischer Durchbruch jemals den Designansatz von SHA-2 kompromittieren, wäre SHA-3 nicht betroffen, weil es völlig anders funktioniert. Es ist eine Versicherungspolice für die kryptografische Gemeinschaft.
SHA-3 gibt es in denselben Ausgabegrößen — SHA3-256, SHA3-384, SHA3-512 — und führt außerdem SHAKE128 und SHAKE256 ein, sogenannte „erweiterbare Ausgabefunktionen", die einen Hash beliebiger Länge erzeugen können.
In der Praxis ist SHA-2 immer noch weiter verbreitet und auf den meisten Hardwareplattformen schneller. Die Verbreitung von SHA-3 wächst, aber es ist eher ein Backup-Standard als ein Ersatz.
Praxisanwendungen
Git-Versionskontrolle: Jeder Commit, jeder Baum und jedes Blob in Git wird durch seinen SHA-1-Hash identifiziert. Wenn Sie git commit ausführen, hasht Git den Inhalt Ihrer Änderungen, die Baumstruktur, den Hash des übergeordneten Commits, Ihre Autoreninfo und den Zeitstempel. Deshalb sehen Commit-Hashes aus wie a1b2c3d4e5f6... — sie sind buchstäblich SHA-1-Digests.
Bitcoin-Mining: Miner konkurrieren darum, einen Nonce-Wert zu finden, der, kombiniert mit den Blockdaten und doppelt mit SHA-256 gehasht, einen Hash unterhalb eines Schwellenwerts erzeugt. Die Schwierigkeit, diesen Hash zu finden, sichert das gesamte Netzwerk. Stand 2024 berechnet das Bitcoin-Netzwerk etwa 500 Trillionen SHA-256-Hashes pro Sekunde.
Datei-Deduplizierung: Cloud-Speicherdienste wie Dropbox hashen jede hochgeladene Datei. Wenn der Hash mit einer bestehenden Datei übereinstimmt, wird kein Duplikat gespeichert — es wird nur ein Verweis hinzugefügt. Das spart enorme Mengen an Speicherplatz.
Digitale Signaturen: Wenn Sie ein Dokument oder ein Software-Release signieren, signieren Sie nicht die gesamte Datei. Stattdessen wird die Datei gehasht, und der Hash wird mit Ihrem privaten Schlüssel signiert. Der Empfänger hasht die Datei selbst und überprüft die Signatur gegen diesen Hash.
API-Authentifizierung: HMAC (Hash-basierter Nachrichtenauthentifizierungscode) kombiniert einen geheimen Schlüssel mit einem Nachrichten-Hash, um sowohl die Integrität als auch die Authentizität von API-Anfragen zu überprüfen. AWS, Stripe und die meisten großen APIs verwenden HMAC-SHA256 für die Anfragensignierung.
Häufige Fehler von Entwicklern beim Hashing
Hash-Funktionen für Passwörter verwenden: Einfaches SHA-256 ist zu schnell für das Passwort-Hashing. Ein Angreifer mit einer GPU kann Milliarden von SHA-256-Hashes pro Sekunde berechnen, was Brute-Force-Angriffe trivial macht. Verwenden Sie immer zweckgebundene Passwort-Hashing-Funktionen wie bcrypt, scrypt oder Argon2, die absichtlich langsam und speicherintensiv sind.
Kein Salt verwenden: Wenn Sie Passwörter ohne Salt hashen (ein zufälliger Wert, der jedem Passwort vor dem Hashing hinzugefügt wird), erzeugen identische Passwörter identische Hashes. Ein Angreifer mit einer vorberechneten „Rainbow Table" kann häufige Passwörter sofort nachschlagen. Fügen Sie immer ein einzigartiges, zufälliges Salt pro Benutzer hinzu.
Hashes auf unsichere Weise vergleichen: Die Verwendung von == zum Vergleichen von Hashes in sicherheitskritischem Code kann Informationen durch Timing-Seitenkanäle preisgeben. Ein Angreifer kann messen, wie lange der Vergleich dauert, und den Hash Zeichen für Zeichen ableiten. Verwenden Sie zeitkonstante Vergleichsfunktionen wie crypto.timingSafeEqual() in Node.js oder hmac.compare_digest() in Python.
Hashes kürzen: Manche Entwickler kürzen Hashes, um Platz zu sparen (z. B. nur die ersten 16 Zeichen eines SHA-256-Hashes speichern). Das reduziert die Kollisionsresistenz dramatisch. Ein vollständiger SHA-256-Hash hat 2^256 mögliche Werte; eine Kürzung auf 16 Hex-Zeichen lässt nur 2^64 übrig — eine Zahl, die moderne Hardware per Brute-Force knacken kann.
Welche Hash-Funktion sollte man verwenden?
- Dateiintegrität (ohne Sicherheitsanforderung): SHA-256 oder sogar MD5 reicht aus. Sie prüfen auf versehentliche Beschädigung, nicht auf böswillige Manipulation.
- Passwortspeicherung: Keine davon! Verwenden Sie bcrypt, scrypt oder Argon2 — sie sind absichtlich langsam, was Brute-Force-Angriffe unpraktisch macht. Reguläre Hash-Funktionen sind zu schnell für Passwort-Hashing.
- Digitale Signaturen und Zertifikate: SHA-256 oder SHA-512.
- HMAC (Nachrichtenauthentifizierung): SHA-256 oder SHA-512.
- Git-artige Inhaltsadressierung: SHA-256 (wohin Git sich bewegt).
- Zukunftssicherheit: Wenn Sie ein System bauen, das Jahrzehnte halten soll, und einen Backup-Plan für den Fall wollen, dass SHA-2 jemals kompromittiert wird, ziehen Sie SHA-3 in Betracht.
- Prüfsummen in Daten-Pipelines: SHA-256 für die Datenintegritätsüberprüfung zwischen Pipeline-Stufen. CRC32 ist schneller, fängt aber nur versehentliche Fehler ab, keine absichtliche Manipulation.
Hash-Funktionen im Code: Praktische Beispiele
Genug Theorie — schreiben wir etwas Code. Ehrlich gesagt ist der beste Weg, Hashing zu verstehen, es einfach... zu tun. So berechnen Sie Hashes in den Sprachen, die Sie wahrscheinlich täglich verwenden.
Node.js — Das eingebaute crypto-Modul macht es kinderleicht:
Und das Coole daran — eine Datei zu hashen ist fast dasselbe:
Python — Pythons hashlib ist genauso unkompliziert. Ich finde tatsächlich, dass Python die schönste API dafür hat:
Go — Gos Standardbibliothek ist dafür unglaublich gut gestaltet:
Java — Etwas ausführlicher (weil... Java), aber funktioniert prima:
Einen Datei-Download verifizieren: Das ist einer der praktischsten Anwendungsfälle von Hashing. Angenommen, Sie laden ein Linux-ISO herunter und die Website sagt, die SHA-256-Prüfsumme sollte abc123... lauten. So überprüfen Sie es:
Ich weiß, das klingt einfach, aber Sie wären überrascht, wie viele Entwickler diesen Schritt überspringen. Ein einziges beschädigtes Byte in einem 4-GB-Download kann Ihnen den ganzen Nachmittag ruinieren.
Rainbow Tables und warum sie erschreckend sind
Okay, jetzt kommt der Teil, der mich umgehauen hat, als ich zum ersten Mal davon erfahren habe. Stellen Sie sich vor, jemand berechnet im Voraus den Hash für jedes mögliche Passwort bis zu, sagen wir, 8 Zeichen. Jede Kombination aus Buchstaben, Zahlen und Symbolen. All diese Hash-zu-Passwort-Zuordnungen werden in einer riesigen Nachschlagetabelle gespeichert.
Das ist eine Rainbow Table. Und sie sind absolut furchteinflößend.
Warum? Wenn Sie Passwörter als einfache SHA-256-Hashes gespeichert haben (ohne Salt), muss ein Angreifer, der Ihre Datenbank erbeutet, nichts „knacken". Er schlägt einfach jeden Hash in seiner Rainbow Table nach. Zack — sofortige Passwortwiederherstellung. Die Suche dauert Mikrosekunden.
Wie groß sind diese Tabellen? Eine Rainbow Table, die alle alphanumerischen Passwörter bis zu 8 Zeichen abdeckt, kann etwa 100-200 GB groß sein. Klingt nach viel, aber das passt auf eine einzige SSD. Seiten wie CrackStation haben Tabellen mit Milliarden vorberechneter Hashes und knacken gängige Passwort-Hashes kostenlos in Sekunden.
Und jetzt die gute Nachricht: Salting macht Rainbow Tables komplett nutzlos. Ein Salt ist einfach eine zufällige Zeichenkette, die vor dem Hashen an das Passwort angehängt wird:
Sehen Sie, was passiert ist? Dasselbe Passwort ("password123") erzeugt völlig unterschiedliche Hashes wegen der verschiedenen Salts. Ein Angreifer müsste für jeden möglichen Salt eine separate Rainbow Table erstellen, was rechnerisch unmöglich ist.
Jede moderne Passwort-Hashing-Bibliothek (bcrypt, Argon2, scrypt) übernimmt das Salting automatisch. Wenn Sie jemals versucht sind, Ihr eigenes Passwort-Hashing zu implementieren — tun Sie es nicht. Ernsthaft. Verwenden Sie bcrypt und machen Sie mit Ihrem Leben weiter.
HMAC: Hashing mit einem Geheimnis
HMAC steht für Hash-basierter Nachrichtenauthentifizierungscode, und ich weiß, das klingt einschüchternd. Aber bleiben Sie dran — es ist eigentlich ein ziemlich einfaches Konzept, das Sie wahrscheinlich schon verwendet haben, ohne es zu wissen.
Reguläres Hashing nimmt eine Nachricht und erzeugt einen Hash. HMAC nimmt eine Nachricht UND einen geheimen Schlüssel und erzeugt einen Hash. Der entscheidende Unterschied (Wortspiel beabsichtigt) ist, dass nur jemand, der den geheimen Schlüssel kennt, den HMAC erzeugen oder verifizieren kann. Es beweist zwei Dinge gleichzeitig: Die Nachricht wurde nicht manipuliert, UND sie stammt von jemandem, der das Geheimnis kennt.
Wo sieht man das in der Praxis? Webhook-Signaturen. Wenn GitHub oder Stripe einen Webhook an Ihren Server sendet, enthalten sie eine HMAC-SHA256-Signatur in den Headers. Ihr Server kann verifizieren, dass der Webhook wirklich von GitHub stammt (und nicht von irgendeinem Angreifer gefälscht wurde), indem er den HMAC selbst berechnet und vergleicht.
Hier ist ein praktisches Beispiel zur Verifizierung einer GitHub-Webhook-Signatur in Node.js:
Beachten Sie den timingSafeEqual-Aufruf? Das ist entscheidend. Ein regulärer ===-Vergleich gibt false zurück, sobald er das erste nicht übereinstimmende Zeichen findet, was bedeutet, dass ein Angreifer die Antwortzeit messen und die Signatur Byte für Byte herausfinden kann. Der zeitkonstante Vergleich dauert immer gleich lang, unabhängig davon, wo die Abweichung auftritt.
Performance-Benchmarks von Hash-Funktionen
Ich verstehe — Performance ist wichtig. Besonders wenn Sie Millionen von Dateien in einer Build-Pipeline hashen oder einen Datenstrom verarbeiten. Hier ist, wie die wichtigsten Hash-Funktionen in Sachen Geschwindigkeit abschneiden (grobe Benchmarks auf moderner x86_64-Hardware):
Moment, haben Sie das mitbekommen? BLAKE3 ist 10x schneller als SHA-256 und dabei kryptografisch sicher. Das ist kein Tippfehler.
BLAKE3 ist das Neueste und Beste in der Hashing-Welt, und das aus gutem Grund. Es basiert auf der BLAKE2-Familie (die im NIST-Wettbewerb bereits SHA-3 übertroffen hat), wurde aber neu gestaltet, um SIMD-Parallelismus und Multithreading zu nutzen. Es kann Daten praktisch mit der Geschwindigkeit von memcpy hashen.
Warum sollte Sie das interessieren? Build-Tools interessiert es. Sehr sogar. Tools wie Bazel, Buck und verschiedene inhaltsadressierte Speichersysteme verbringen eine erstaunliche Menge Zeit mit dem Hashen von Dateien. Der Wechsel von SHA-256 zu BLAKE3 kann die Abhängigkeitsprüfung um eine Größenordnung beschleunigen. Das Rust-Ökosystem setzt BLAKE3 bereits aggressiv ein, und es taucht an immer mehr Stellen auf.
Dennoch sind SHA-256 und SHA-512 immer noch die richtige Wahl, wenn Sie breite Kompatibilität oder die Einhaltung von Standards wie FIPS benötigen. Noch nicht alles unterstützt BLAKE3, und in vielen Anwendungsfällen ist die Hashing-Geschwindigkeit sowieso nicht der Engpass.
Blockchain und Merkle-Bäume: Hashing im großen Maßstab
Okay, jetzt wird es richtig spannend. Sie wissen, wie Git Ihnen genau sagen kann, welche Datei sich in einem riesigen Repository geändert hat? Und wie Bitcoin eine Transaktion verifizieren kann, ohne die gesamte Blockchain herunterzuladen? Das Geheimnis ist eine Datenstruktur namens Merkle-Baum (benannt nach Ralph Merkle, der ihn 1979 patentierte).
Ein Merkle-Baum ist im Grunde ein Baum aus Hashes. So funktioniert es — stellen Sie sich vier Datenblöcke vor:
Jeder Blattknoten ist der Hash eines Datenblocks. Jeder Elternknoten ist der Hash seiner beiden verketteten Kinder. Der Root-Hash (manchmal „Merkle-Root" genannt) ist ein einzelner Hash, der ALLE Daten im Baum repräsentiert.
Hier kommt der wirklich elegante Teil: Wenn sich auch nur ein Bit von Data C ändert, ändert sich Hash(C), was bedeutet, dass sich Hash(CD) ändert, was bedeutet, dass sich der Root-Hash ändert. Sie können Manipulation sofort erkennen, indem Sie nur den Root-Hash prüfen.
Aber es wird noch besser. Angenommen, Sie möchten beweisen, dass Data C Teil des Baums ist, ohne Data A, B oder D preiszugeben. Sie müssen nur liefern: Data C, Hash(D) und Hash(AB). Der Verifizierer kann den Pfad bis zum Root rekonstruieren und prüfen, ob er übereinstimmt. Das nennt man einen „Merkle-Beweis", und er ist unglaublich effizient — für einen Baum mit einer Million Blättern ist der Beweis nur etwa 20 Hashes lang (log2 von 1.000.000).
Wo wird das in der Praxis eingesetzt?
- Git: Ihr gesamtes Repository ist ein Merkle-Baum. Commits zeigen auf Trees, Trees zeigen auf Blobs, und alles wird durch seinen SHA-1-Hash identifiziert. Deshalb kann Git sofort erkennen, ob sich etwas geändert hat.
- Bitcoin: Jeder Block enthält einen Merkle-Root aller Transaktionen. Light Clients (wie mobile Wallets) können eine bestimmte Transaktion mit einem Merkle-Beweis verifizieren, ohne den vollständigen Block herunterzuladen.
- IPFS: Das InterPlanetary File System zerlegt Dateien in Chunks, baut einen Merkle-DAG (gerichteten azyklischen Graphen) und verwendet den Root-Hash als Content Identifier (CID) der Datei.
- Certificate Transparency: Googles Certificate-Transparency-Logs verwenden Merkle-Bäume, damit jeder effizient überprüfen kann, ob ein Zertifikat protokolliert wurde (oder nicht).
Die Zukunft: Post-Quantum-Hash-Funktionen
Sie haben vielleicht gehört, dass Quantencomputer all unsere Verschlüsselung brechen werden. Und ja, das stimmt teilweise — RSA, ECC und Diffie-Hellman sind alle erledigt, sobald großformatige Quantencomputer verfügbar sind. Shors Algorithmus kann große Zahlen effizient faktorisieren und diskrete Logarithmen berechnen, worauf diese Systeme basieren.
Aber hier ist die überraschend gute Nachricht: Hash-Funktionen sind gegen Quantencomputer eigentlich ziemlich sicher. Die hauptsächliche Quantenbedrohung für Hash-Funktionen ist Grovers Algorithmus, der einen unstrukturierten Suchraum quadratisch schneller durchsuchen kann. In der Praxis bedeutet das, dass die Sicherheitsbits halbiert werden — SHA-256 geht von 2^256 auf 2^128 Stärke gegen Quantenangriffe.
2^128 ist immer noch absolut riesig. Das ist ungefähr die Anzahl der Atome im beobachtbaren Universum zum Quadrat. Niemand wird das per Brute-Force knacken, Quantencomputer hin oder her.
Während also NIST aktiv an Post-Quantum-Kryptografie-Standards arbeitet (und 2024 mehrere finalisiert hat), liegt die Dringlichkeit hauptsächlich bei Public-Key-Verschlüsselung und Signaturen — nicht bei Hash-Funktionen. Wenn Sie heute SHA-256 verwenden, können Sie ruhig schlafen in dem Wissen, dass Quantencomputer es nicht nutzlos machen werden.
Wenn Sie allerdings wirklich paranoid sind (und in der Kryptografie ist Paranoia eine Tugend), bietet ein Wechsel zu SHA-512 oder SHA3-256 eine zusätzliche Sicherheitsmarge. Einige Post-Quantum-Signaturverfahren wie SPHINCS+ basieren sogar komplett auf Hash-Funktionen, was ein schönes Vertrauensvotum für ihre Quantenresistenz ist.
Hash-Kollisionen: Birthday-Angriffe erklärt
Sprechen wir über eines der unintuitivsten Dinge in der gesamten Informatik: den Birthday-Angriff. Er ist nach dem Geburtstagsparadoxon benannt, und er ist der Grund, warum Hash-Funktionen größer sein müssen, als man intuitiv erwarten würde.
Hier ist das Geburtstagsparadoxon: In einem Raum mit nur 23 Personen besteht eine 50%-ige Chance, dass zwei von ihnen am selben Tag Geburtstag haben. Nicht an einem bestimmten Datum — einfach irgendein übereinstimmendes Paar. Bei 70 Personen springt die Wahrscheinlichkeit auf 99,9%. Die meisten vermuten, man bräuchte etwa 183 Personen (die Hälfte von 365), aber die tatsächliche Zahl ist viel niedriger, weil wir nach IRGENDEINER Kollision suchen, nicht nach einer bestimmten.
Genau dieselbe Mathematik gilt für Hash-Funktionen. Wenn eine Hash-Funktion N mögliche Ausgaben hat, muss man nicht N Hashes berechnen, um eine Kollision zu finden — man braucht nur ungefähr die Quadratwurzel von N.
Für einen 256-Bit-Hash wie SHA-256 gibt es 2^256 mögliche Ausgaben. Eine Kollision zu finden erfordert ungefähr 2^128 Operationen (die Quadratwurzel von 2^256). Das ist immer noch eine unmöglich große Zahl — aber es ist der Grund, warum wir nicht einfach einen 64-Bit-Hash verwenden und fertig sein können.
Genau deshalb ist MD5 (128 Bit) zusammengebrochen. Seine Kollisionsresistenz betrug von Anfang an nur 2^64, und strukturelle Schwächen im Algorithmus haben sie noch weiter reduziert. Forscher fanden schließlich Kollisionen in Sekunden auf einem normalen Laptop.
Das praktische Fazit? Verwenden Sie immer mindestens eine 256-Bit-Hash-Funktion für alles, was mit Sicherheit zu tun hat. SHA-256, SHA3-256 oder BLAKE3 sind allesamt ausgezeichnete Wahlen. Und wenn jemand vorschlägt, einen 64-Bit- oder 128-Bit-Hash für Sicherheitszwecke zu verwenden, wissen Sie jetzt genau, warum das eine schlechte Idee ist.
Selbst ausprobieren
Neugierig, welchen Hash Ihre Daten erzeugen? Nutzen Sie unseren MD5-Hash-Generator, SHA-256-Hash-Generator oder SHA-512-Hash-Generator. Geben Sie Text ein und sehen Sie, wie selbst kleinste Änderungen völlig andere Hashes erzeugen — der beste Weg, ein Gespür für das Verhalten dieser Algorithmen zu entwickeln.