Die erste Zeile hält die genauen verwendeten Parameter fest (Algorithmus, Lesart, Eingabegrößen), sodass ein kopiertes Ergebnis immer reproduzierbar ist.
HMAC, PBKDF2 und HKDF — schlüsselgebundenes Hashing von Grund auf erklärt
In einem Satz: Ein nackter Hash wie SHA-256 kann jeder berechnen, er beweist also nichts darüber, wer eine Nachricht gesendet hat — HMAC mischt einen geheimen Schlüssel ein, sodass nur Schlüsselinhaber den Digest erzeugen (oder prüfen) können; PBKDF2 und HKDF nutzen dann dieselbe HMAC-Maschinerie, um Geheimnisse in Schlüssel zu verwandeln — für Passwörter langsam, für bereits zufälliges Material schnell.
Was HMAC ist (RFC 2104)
Die Konstruktion. HMAC sind zwei Hash-Durchläufe, nicht einer. Ihr Schlüssel wird auf die Blockgröße des Hashes aufgefüllt (64 Byte für MD5/SHA-1/SHA-256, 128 für SHA-384/512); die Nachricht wird einmal mit dem Schlüssel XOR einem festen inneren Pad gehasht, und dieser Digest wird erneut gehasht mit dem Schlüssel XOR einem festen äußeren Pad. Diese Doppel-Sandwich-Konstruktion ist beweisbar sicher, solange der zugrunde liegende Hash eine brauchbare pseudozufällige Funktion ist — deshalb widersteht HMAC-MD5 noch praktischen Kollisionsangriffen, die reines MD5 brachen (auch wenn es ohnehin ausgemustert ist, siehe unten).
Schlüssel. Jede Schlüssellänge funktioniert: Kürzer als die Blockgröße wird unverändert verwendet (aber unter 32 Byte sieht man ungern), längere werden zuerst gehasht. Dieselbe Seite lässt Sie den Schlüssel als Text, Hex oder Base64 eingeben, damit ein 64-Hexzeichen-Produktionsschlüssel eingefügt werden kann, ohne dass ihn jemand mit einem 64-Zeichen-Textpasswort verwechselt — die Lesart wird aus genau diesem Grund in der Ausgabezeile festgehalten.
Wo man ihm begegnet. Das Feld HS256 im JWT-Header ist wörtlich HMAC-SHA-256 über die base64url-kodierten Teile des Tokens (der JWT-Decoder dieser Website berechnet genau das, wenn Sie ein HS256-Geheimnis einfügen). Webhook-Signaturen (Stripe, GitHub), AWS SigV4, TLS-Record-Schutz (ältere Versionen) und der OpenSSH-Verwandte umac-64@openssh.com gehören alle zur selben Familie.
Warum nicht einfach hash(message || key)? Längenerweiterung: Jeder Hash der MD5-/SHA-1-/SHA-2-Familie erlaubt einem Angreifer, der H(secret || msg) kennt, H(secret || msg || padding || beliebig) ohne das Geheimnis zu berechnen. Die innere/äußere Trennung von HMAC beseitigt diese Angriffsklasse. Es ist der häufigste Selbstbau-Fehler in API-Signaturcode — und der Grund, warum es HMAC gibt.
Was PBKDF2 ist (RFC 8018)
Absichtlich langsam. Ein Passwort hat vielleicht 40 Bit echte Entropie; die GPU eines Angreifers probiert Milliarden rohe SHA-256 pro Sekunde. PBKDF2 führt HMAC(password, salt) immer wieder aus — iter-mal — sodass jeder Rateversuch Sie und den Angreifer dieselben iter HMACs kostet. Der Standard hier sind 600.000 Iterationen mit HMAC-SHA-256, der Ausgangswert des OWASP-Spickzettels zur Passwortspeicherung; der Regler geht bis zehn Millionen, weil die Sicherheitsempfehlungen mit steigender Hardware-Geschwindigkeit nach oben wandern.
Salt. Ein zufälliges Salt pro Passwort bedeutet, dass identische Nutzer nicht mehr identisch gehasht werden, und vorberechnete Tabellen (Rainbow-Tabellen) wertlos werden. Es ist nicht geheim — es wird neben dem Hash gespeichert — es muss nur eindeutig sein. 16 zufällige Bytes sind der Standard.
Bekannte Schwäche. PBKDF2 ist CPU-hart, aber nicht speicherhart: GPUs und ASICs parallelisieren es hervorragend. Deshalb lautet der moderne Rat scrypt oder Argon2id, wo ein Passwort-Hash-Speicher entworfen wird (die Seite Passwort-Hash-Generator dieser Familie behandelt sie), und PBKDF2 bleibt die richtige Antwort für Kompatibilität und FIPS-140-Einstellungen.
Was HKDF ist (RFC 5869)
Extrahieren, dann expandieren. HKDF erledigt zwei Aufgaben. Extrahieren: möglicherweise ungleichmäßiges Eingangsschlüsselmaterial (etwa ein Diffie–Hellman-Geheimnis) zusammen mit einem Salt zu einem kurzen pseudozufälligen Schlüssel PRK = HMAC(salt, IKM) verdichten. Expandieren: diesen PRK auf eine beliebige Länge bis zu 255 Hash-Blöcken strecken, wobei jeder Ausgabeblock an den vorherigen gekettet und durch das Feld info markiert wird. Ergebnis: Ein einziges Geheimnis kann Ihnen sicher einen Verschlüsselungsschlüssel, einen MAC-Schlüssel und einen IV geben, alle getrennt.
Nicht für Passwörter. HKDF setzt voraus, dass seine Eingabe bereits volle Entropie hat — es führt pro 32 Ausgabebytes ein HMAC aus, daher läuft ein menschliches Passwort praktisch sofort hindurch, genau was ein Angreifer will. Passwörter über HKDF statt PBKDF2 zu leiten ist ein klassischer Designfehler; das Feld info dient Zweckbezeichnungen ("client traffic key", "server iv"), nicht zusätzlicher Entropie.
Wo man ihm begegnet. TLS 1.3 leitet jeden Schlüssel, den es nutzt, über HKDF aus dem Handshake-Geheimnis ab; WireGuard, Signal, EAP-TLS 1.3 und JSON Web Encryption (als direkte Schlüsselvereinbarungs-KDF) gehören alle zum selben Stammbaum.
Ankerwerte — auf dieser Seite nachvollziehbar
Die ersten beiden Tabellen sind die Testvektoren, auf denen die Schaltfläche Beispiel und der Selbsttest dieser Seite aufbauen (Schlüssel "key", Nachricht „The quick brown fox jumps over the lazy dog“; danach der RFC-artige Fall mit einem 16-Byte-Schlüssel 0x0b und der Nachricht „Hi There“). Alle wurden von einer unabhängigen nativen Implementierung erzeugt und auf dieser Seite erneut geprüft.
HMAC von „fox“, Schlüssel = key | Digest (Hex) |
|---|
| HMAC-MD5 | 80070713463e7749b90c2dc24911e275 |
| HMAC-SHA-1 | de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9 |
| HMAC-SHA-256 | f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8 |
| HMAC-SHA-384 | d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237 |
| HMAC-SHA-512 | b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a |
| KDF-Anker | Parameter | Ausgabe (Hex, erste Bytes) |
|---|
| PBKDF2-HMAC-SHA-1 | password / salt, c=4096, 32 Byte | 4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db |
| PBKDF2-HMAC-SHA-256 | password / salt, c=4096, 32 Byte | c5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a |
| HKDF-SHA-256 (RFC 5869 A.1) | IKM=0x0b×22, salt=00..0c, info=f0..f9, L=42 | 3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865 |
| HKDF-SHA-256 (RFC 5869 A.2) | IKM=00..4f, salt=60..af, info=b0..ff, L=82 | b11e398dc80327a1c8e7f78c596a49344f012eda2d4efad8a050cc4c19afa97c… |
| HKDF-SHA-256 (RFC 5869 A.3) | IKM=0x0b×22, leerer Salt und info, L=42 | 8da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8 |
Häufige Fehler
- HMAC mit Verschlüsselung verwechseln. HMAC beweist Integrität und Herkunft (bei einem gemeinsamen Geheimnis); es verbirgt nichts. Wer den Schlüssel nicht hat, sieht die vollständige Nachricht trotzdem.
- HMAC mit einer Signatur verwechseln. Digitale Signaturen sind Public-Key: Einer signiert, jeder prüft. HMAC ist symmetrisch: Jeder Prüfer könnte auch fälschen. Für Nichtabstreitbarkeit brauchen Sie RSA/ECDSA (siehe das RSA-Werkzeug dieser Familie, sobald veröffentlicht), nicht HMAC.
- Verwechslungen bei der Schlüssel-Lesart. Eine 64-Zeichen-Hex-Zeichenfolge, die in ein Textschlüsselfeld eingefügt wird, wird zu 64 Byte, nicht 32 — und das HMAC ändert sich völlig. Diese Seite schreibt die Lesart in die Ausgabezeile; wenn zwei Werkzeuge widersprechen, ist das der erste Punkt zum Vergleichen.
- PBKDF2-Iterationen zu niedrig. 1.000 Iterationen waren 2000 vernünftig; heute frisst sie eine GPU-Farm. Wenn Ihr System noch 1.000-Iterations-Hashes speichert, planen Sie eine Migration mit Neuhashing beim Login.
- HKDF auf einem Passwort. Ein HMAC pro Ausgabeblock heißt, dass ein Passwort sofort hindurchläuft — verwenden Sie PBKDF2 (oder Argon2id) für Passwörter und HKDF für Geheimnisse mit hoher Entropie.
- Einen abgeleiteten Schlüssel für alles wiederverwenden. Die Lösung kostet nichts: Leiten Sie getrennte Schlüssel mit unterschiedlichen
info-Bezeichnungen ab. Zwei Schlüssel aus einem IKM mit unterschiedlichen Bezeichnungen sind per Konstruktion unabhängig.
FAQ
Ist HMAC-MD5 gebrochen? Als kollisionsresistenter Hash ist MD5 tot, aber die Sicherheit von HMAC-MD5 hängt von MD5 als pseudozufälliger Funktion ab, und es ist kein praktischer Bruch bekannt. Trotzdem ausgemustert — es gibt keinen Grund, es HMAC-SHA-256 vorzuziehen, außer der Kompatibilität mit einem alten Protokoll.
Wie lang sollte mein HMAC-Schlüssel sein? Mindestens so lang wie die Ausgabegröße des Hashes (32 Byte für SHA-256) und von einem kryptografisch sicheren Zufallsgenerator erzeugt. Ein Schlüssel, der kürzer als der Digest ist, ist erlaubt, aber jedes Bit darunter verringert die Sicherheit direkt.
Wird PBKDF2 mit mehr Iterationen unbegrenzt „sicherer“? Es erhöht die Kosten des Angreifers linear, aber auch Ihre eigenen Anmeldekosten linear. Die Kunst ist, die größte Anzahl zu wählen, die Ihre Nutzer tolerieren — genau dafür kalibrieren die Zahlen der OWASP.
Warum ist HKDF auf 255 × Hash-Größe begrenzt? Die Expand-Schleife lautet T(i) = HMAC(PRK, T(i-1) || info || i) mit einem Ein-Byte-Zähler i — 255 ist der größte Zählerwert, eine harte strukturelle Grenze von RFC 5869, keine Richtlinienentscheidung.
Worin unterscheidet sich PBKDF2 auf dieser Seite vom Passwort-Hash-Generator? Gleicher Algorithmus, andere Aufgabe. Diese Seite leitet rohe Schlüsselbytes für Sie ab, die Sie anderswo verwenden; die Passwort-Hash-Seite erzeugt gespeicherte Anmeldedaten-Zeichenfolgen (mit eingebettetem Salt und Parametern) und prüft eingefügte Kandidaten dagegen.
