HMAC-Generator

Was ist HMAC?#

HMAC steht für Hash-based Message Authentication Code. Ein einfacher Hash (wie SHA-256) beantwortet die Frage „hat sich dieser Byte-Strom geändert?“. HMAC beantwortet eine stärkere: „hat sich dieser Byte-Strom geändert, und wurde er von jemandem gesendet, der tatsächlich meinen geheimen Schlüssel teilt?“. Der Unterschied zählt immer dann, wenn eine Nachricht über einen Kanal reist, dem Sie nicht vollständig vertrauen — Webhook-Callbacks, signierte URLs, API-Request-Signing, Service-zu-Service-Tokens.

Mechanisch mischt HMAC einen geheimen Schlüssel auf definierte Weise in die Hash-Funktion ein (zwei Runden, mit Padding), sodass der Digest ohne den Schlüssel nicht gefälscht werden kann. Die Ausgabe ist ein Byte-String fester Länge, dessen Größe der zugrundeliegenden Hash entspricht: 20 Bytes für SHA-1, 32 für SHA-256, 48 für SHA-384, 64 für SHA-512.

Diese Seite berechnet HMAC in Ihrem Browser über die Web-Crypto-API. Sie wählen den Hash, fügen Nachricht und Secret ein und erhalten den Digest als Hex oder Base64.

Verwendung#

1. Tippen oder fügen Sie die Nachricht ein — die Nutzlast, die Sie authentifizieren möchten. Das sind die Bytes, die der Empfänger auf seiner Seite hashen wird.
2. Geben Sie den Geheimen Schlüssel ein. Das Feld ist standardmäßig maskiert; klicken Sie auf die Augenschaltfläche rechts, um ihn beim Tippen zu zeigen. Schlüssel und Nachricht werden beide als UTF-8 kodiert.
3. Wählen Sie den Algorithmus:
   • SHA-1 — 160-Bit. Schnell, aber nur für veraltetes HMAC geeignet (einige ältere Signing-Flows verlangen es noch). Verwenden Sie SHA-1 nicht für digitale Signaturen.
   • SHA-256 — 256-Bit. Der moderne Standard; die große Mehrheit der Webhook-Signaturen (Stripe, GitHub, Slack-artige Flows) verwendet HMAC-SHA-256.
   • SHA-384 / SHA-512 — längere Digests, marginal mehr Kollisionsresistenz, geringfügig langsamer. Wählen Sie einen, wenn das empfangende System ihn ausdrücklich verlangt.
4. Wählen Sie die Ausgabe-Kodierung: Hex (typisch für X-Signature-artige Header) oder Base64 (typisch, wenn der Digest in JSON oder einem Token eingebettet ist).
5. Klicken Sie auf Erzeugen. Der Digest erscheint in der rechten Fläche; die Statuszeile zeigt den Algorithmus und die Bytelänge als Sanity-Check. Kopieren, um ihn zu übernehmen.

Eckpunkte#

• Auf Web Crypto gestützt. Verwendet das native crypto.subtle des Browsers, dieselbe Primitiv-Produktionscode verwendet — keine JavaScript-Neuimplementation.
• Längen-Sanity-Check. Jeder Digest wird gegen die erwartete Bytelänge seines Algorithmus verifiziert, sodass ein abgeschnittenes oder manipuliertes Ergebnis nicht stillschweigend durchrutscht.
• Hex- oder Base64-Ausgabe. Wechsel mit einem Klick; kein Neutippen.
• Secret bleibt lokal. Das Schlüsselfeld wird als Passwort-Eingabe gerendert und verlässt niemals die Seite — es gibt kein Backend.
• Sicherer Kontext beachtet. Würde die Seite jemals über unverschlüsseltes HTTP geladen, ist crypto.subtle nicht verfügbar und das Werkzeug meldet das ausdrücklich, statt eine falsche Antwort zu liefern.

Konkretes Beispiel#

Das klassische Referenzpaar (RFC 4231) verwendet einen Schlüssel Jefe und die Nachricht what do ya want for nothing?. Mit dieser Seite auf SHA-256 und Hex lautet der Digest:

5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843

Schalten Sie auf SHA-512 mit denselben Eingaben und der Digest verdoppelt sich in der Länge:

164b7a7bfcf819e2e395fbe73b56e0a387bd64222e831fd610270cd7ea2505549758bf75c05a994a6d034f65f8f0e6fdcaeab1a34d4a6b4b636e070a38bce737

Sie können beides genau hier reproduzieren: Beispiel laden, dann Erzeugen. Genau dieses Paar ist auch, wie die eigene Test-Suite dieses Werkzeugs die Korrektheit verifiziert — wenn Sie je einen anderen Digest erhalten, wurde die Seite manipuliert.

FAQ#

SHA-256 oder SHA-512 — was sollte ich verwenden?#

Für HMAC im Besonderen ist SHA-256 der pragmatische Standard: jeder große Webhook-Signer verwendet es, es ist schnell, und 256-Bit-Digests liegen bereits weit jenseits der Brute-Force-Reichweite. Wechseln Sie zu SHA-512 nur, wenn (a) das empfangende System es verlangt oder (b) Sie ein neues Protokoll von Grund auf entwerfen und die zusätzliche Kollisionsmarge zu bescheidenem Geschwindigkeitskosten wollen. Vermeiden Sie SHA-1 vollständig, es sei denn, Sie matchen ein Altsystem, das es vorschreibt.

Ist HMAC dasselbe wie die Nachricht zu verschlüsseln?#

Nein. HMAC authentifiziert nur — es beweist, dass die Nachricht nicht verändert wurde und von jemandem stammt, der den Schlüssel hält. Die Nachricht selbst bleibt im Klartext. Wenn Sie auch Vertraulichkeit brauchen, paaren Sie HMAC mit einem Verschlüsselungs-Schema oder verwenden Sie einen authentifizierten Verschlüsselungs-Modus wie AES-GCM.

Kann der geheime Schlüssel aus dem Digest wiederhergestellt werden?#

Nein. Der Digest ist eine Einweg-Funktion sowohl der Nachricht als auch des Schlüssels; das Wiederherstellen des Schlüssels aus Ausgaben ist rechnerisch undurchführbar. Das gesagt, ein kurzer oder ratbarer Schlüssel kann dennoch durch Offline-Ausprobieren von Kandidatenschlüsseln brute-forcet werden — verwenden Sie also einen Schlüssel mit mindestens 128 Bits echter Entropie, kein menschengewähltes Passwort.

Der Empfänger sagt, meine Signatur passe nicht. Was prüfe ich zuerst?#

Neun von zehn Mal ist es die Byte-Darstellung der Nachricht: abschließende Zeilenumbrüche, URL-Kodierung versus roher Body, JSON-Whitespace oder eine andere Feldreihenfolge. Vergleichen Sie die exakten Bytes, die Sie signiert haben, gegen die exakten Bytes, die der Empfänger gehasht hat, Zeichen für Zeichen, bevor Sie etwas anderes prüfen.