Berechnen Sie HMAC-SHA-256- und HMAC-SHA-512-Signaturen mit Ihrem geheimen Schlüssel — direkt in Ihrem Browser.
HMAC (Hash-based Message Authentication Code, RFC 2104) kombiniert einen geheimen Schlüssel mit einer Nachricht zu einer Signatur, die nur jemand mit demselben Schlüssel reproduzieren kann. Es ist der Mechanismus hinter den meisten Webhook-Verifikationen — Stripe, GitHub, Shopify und Slack signieren ihre Webhook-Payloads alle mit HMAC-SHA-256 — sowie hinter signierten URLs, API-Request-Signierung und Integritätsprüfungen von Session-Tokens. Wenn eine Webhook-Validierung fehlschlägt, ist das manuelle Berechnen der erwarteten Signatur mit diesem Tool meist der schnellste Weg, die Abweichung zu finden.
Die Berechnung nutzt SubtleCrypto, die native WebCrypto-API des Browsers: Der Schlüssel wird mit crypto.subtle.importKey importiert und die Signatur mit crypto.subtle.sign erzeugt — die Kryptographie ist also die auditierte Implementierung des Browsers selbst, statt dass JavaScript sie neu erfindet. HMAC ist nicht einfach hash(key + message): Es hasht zweimal und mischt den Schlüssel mit zwei verschiedenen Paddings (siehe Formel unten), was die Length-Extension-Angriffe ausschließt, die die naive Konstruktion brechen. Die Ausgabe hier reproduziert die RFC-4231-Testvektoren exakt.
Ihr geheimer Schlüssel verlässt den Browser nie: Dieses Tool stellt keine Netzwerkanfragen, lädt nichts hoch und speichert nichts — das können Sie im Netzwerk-Tab der Entwicklertools Ihres Browsers überprüfen. Zwei praktische Hinweise für Produktionscode: Vergleichen Sie Signaturen immer mit einem zeitkonstanten Vergleich, um Timing-Angriffe zu vermeiden, und stellen Sie sicher, dass beide Seiten exakt dieselben Bytes signieren — ein unsichtbarer Zeilenumbruch am Ende oder ein neu serialisierter JSON-Body ist die häufigste Ursache abweichender HMACs.
HMAC(K, m) = H((K xor opad) || H((K xor ipad) || m)), wobei H die Hash-Funktion ist und ipad (Byte 0x36) und opad (Byte 0x5c) auf die Blockgröße des Hashes wiederholt werden. Das verschachtelte doppelte Hashing verhindert die Length-Extension-Angriffe, die naive hash(key + message)-Konstruktionen brechen.
Er beweist, dass eine Nachricht von jemandem mit dem geheimen Schlüssel stammt und unterwegs nicht verändert wurde. Typische Einsätze: Verifizieren von Webhook-Payloads (Stripe, GitHub, Shopify), Signieren von API-Requests und Schutz von URLs oder Cookies vor Manipulation.
Nein. Schlüssel und Nachricht werden zu 100% lokal von der WebCrypto-API Ihres Browsers verarbeitet — nichts wird übertragen, protokolliert oder irgendwo gespeichert.
Fast immer ein Kodierungsunterschied: ein Zeilenumbruch am Ende, ein neu serialisierter JSON-Body, UTF-8 gegenüber einer anderen Kodierung oder eine Hex-Ausgabe im Vergleich mit Base64. Signieren Sie exakt dieselben Bytes mit demselben Schlüssel, und die Signaturen stimmen überein.
Beide gelten als sicher. HMAC-SHA-256 ist der Industriestandard und das, was die meisten Webhook-Anbieter nutzen; wählen Sie HMAC-SHA-512, wenn die Gegenseite eine Signatur mit 128 Zeichen erwartet.
Nein. HMAC authentifiziert eine Nachricht, verbirgt sie aber nicht — jeder kann den Inhalt weiterhin lesen. Verwenden Sie Verschlüsselung für Vertraulichkeit und HMAC (oder beides, wie bei authentifizierter Verschlüsselung) für Integrität und Authentizität.
Vai.la verwandelt jede URL in einen Kurzlink mit Klick-Statistiken, QR-Code und Ihrem eigenen Biolink.
Vai.la übernimmt keine Verantwortung für die Nutzung der Tools oder für Entscheidungen, die auf ihren Ergebnissen basieren.