HMAC と普通のハッシュ（SHA-256 など）は何が違いますか？

違いは『秘密鍵を使うかどうか』です。普通のハッシュは本文だけから値が決まるので、本文を書き換えた人がハッシュも作り直せます。HMAC は秘密鍵を混ぜて計算するため、鍵を知らない相手は正しい値を作れず、改ざん検知と送信元の確認ができます。

どのアルゴリズムを選べばよいですか？

送信先（API や Webhook）が指定する方式に合わせます。指定が HMAC-SHA256 なら SHA-256 を選びます。新規に自分で決める場合は SHA-256 以上を推奨します。HMAC-SHA-1 は既存システムとの互換用にのみ使ってください。

16進と Base64 はどちらを使えばよいですか？

受け取る側の仕様に合わせます。GitHub の Webhook 署名は16進小文字（sha256= に続く形）、多くの API 署名は Base64 を使います。本ツールは両方を同時に表示するので、必要な方をコピーしてください。

同じ入力なのに他のツールと値が違います。なぜですか？

多くの場合は鍵やメッセージのエンコード（本ツールは UTF-8）や、末尾の改行・空白の有無、鍵を16進やBase64として解釈しているかどうかの違いです。本ツールは鍵・メッセージをそのまま UTF-8 バイト列として扱います。改行や余分な空白が入っていないかも確認してください。

秘密鍵やメッセージはサーバーに送られますか？

送られません。計算はすべてブラウザ内の Web Crypto API で行われ、鍵もメッセージもどこにも送信されません。オフラインでも利用できます。

Webhook の署名検証にそのまま使えますか？

はい。受信した本文を「メッセージ」に、自分の Webhook シークレットを「秘密鍵」に入れて計算し、送信元が付けた署名ヘッダーと突き合わせます。値が一致すれば正当な送信元からのリクエストと判断できます。実運用のコードでは、比較は定数時間比較を使うのが安全です。

計算結果が「—」のまま表示されません。

メッセージと秘密鍵の両方が入力されていないと計算しません。両方を入力してください。また Web Crypto はセキュアな接続（HTTPS）でのみ動作するため、その環境かどうかもご確認ください。

鍵はどのくらいの長さが必要ですか？

用途によりますが、推測されにくい十分に長くランダムな値を使ってください。短い・単純な鍵は総当たりで破られやすくなります。鍵が漏れると誰でも正しい署名を作れてしまうため、鍵の管理には十分注意してください。

🔑 HMAC生成

メッセージと秘密鍵から HMAC（鍵付きハッシュ）を計算します。HMAC-SHA-1 / SHA-256 / SHA-384 / SHA-512 に対応し、16進（大文字・小文字）と Base64 を併記。API リクエストの署名や Webhook の検証にそのまま使えます。

HMAC値 (HMAC-SHA-256)

16進小文字大文字

—

Base64

—

※ 計算はすべてブラウザ内（標準の Web Crypto API：crypto.subtle.importKey ＋ sign）で行い、秘密鍵もメッセージもサーバーに送信しません。鍵・本文は UTF-8 でバイト列化します。HMAC は秘密鍵を知る相手だけが同じ値を再現できる「鍵付き」のハッシュで、鍵を持たない第三者は正しい値を作れません。

HMAC とは・使いどころ

HMAC（Hash-based Message Authentication Code）は、メッセージと秘密鍵の2つを材料にハッシュ値を作る仕組みです。単なる SHA-256 などのハッシュは本文だけから決まるため、本文を書き換えた人がハッシュも計算し直せてしまいます。HMAC は秘密鍵を混ぜるため、鍵を知らない第三者は正しい値を作れません。これにより「本文が改ざんされていないこと」と「送り主が鍵を共有した本人であること」を同時に確かめられます。

API リクエストの署名：本文やタイムスタンプを鍵で HMAC 化し、ヘッダーに付けて送る（AWS SigV4、各種 Web API の署名方式など）。
Webhook の検証：GitHub / Stripe などが送る署名ヘッダー（例 X-Hub-Signature-256）を、自分の鍵で計算した HMAC と突き合わせて正当な送信元か確認する。
改ざん検知：保存・転送するデータに HMAC を添え、受信側で再計算して一致を確認する。