HMACジェネレーター

このツールとは？

HMAC は Hash-based Message Authentication Code の略です。秘密鍵とメッセージを SHA-256 のような標準的なハッシュ関数と組み合わせ、固定長のダイジェストを生成します。同じ鍵と同じメッセージを持つ者であれば誰でも同一の HMAC を計算できますが、鍵を知らなければ、使われているハッシュアルゴリズムがわかっていたとしても、メッセージに対する正しい HMAC を作ることは計算量的に事実上不可能です。

これが単なるハッシュとの決定的な違いです。MD5 や SHA-256 のような単純なハッシュは入力としてメッセージしか受け取らないため、誰でも計算でき、誰が作成したかは何も証明しません。HMAC はメッセージ「と」秘密鍵の両方を入力とするため、正しい HMAC が存在すること自体が、送信者がその秘密鍵を保持していたことの証明になります。つまり整合性チェックではなく、認証の仕組みなのです。

HMAC は NIST の FIPS 198-1 で正式に標準化されており、インターネットプロトコル向けには IETF RFC 2104 で定義されています。このツールはブラウザネイティブの Web Crypto API（HMAC アルゴリズムを指定した `crypto.subtle.sign`）を使って計算しており、自前実装の JavaScript ではなく RFC 2104 を正しく実装したエンジンで動作します。

なぜこれを使うのか？

• Stripeから届いたWebhookのX-Stripe-Signatureヘッダーが本当に正しい署名なのか、サーバーのログを疑う前に手元で再現して確認したいとき――秘密鍵とペイロードをこのツールに入力し、生成されたHMAC-SHA256がヘッダーの値と一致するか照合できます。
• GitHub Appsのwebhook実装をローカルで書いていて、X-Hub-Signature-256の検証ロジックが正しく動いているか確信が持てないとき――既知のペイロードと秘密鍵で期待値を先に計算しておき、自作コードの出力と突き合わせてデバッグできます。
• 社内APIの署名付きリクエストを別チームのAPIクライアントが正しく実装できているか確認する必要があるとき――同じ秘密鍵とメッセージを渡して、双方が同じHMACを得られるかその場で検証できます。
• JWTのHS256署名部分が期待通りかを、ライブラリのブラックボックスに頼らず自分の目で確認したいとき――ヘッダーとペイロードを結合した文字列をメッセージ欄に入力し、署名鍵でHMAC-SHA256を計算して照合できます。
• 本番環境の秘密鍵を使ったテストを外部サービスに一切送信せずに行いたいとき――計算はすべてブラウザ内で完結するため、実際のシークレットを入力しても外部に漏れる心配がありません。
• SHA-1とSHA-256でHMACの出力長がどれだけ変わるかを、ドキュメントを読むより先に実際の数値で確かめたいとき――同じ鍵とメッセージに対する4種類のアルゴリズムの結果を一度に並べて比較できます。

使い方

1. 「Secret Key」欄に秘密鍵を入力します。
2. 「Message」欄に認証したいメッセージを入力します。
3. HMAC-SHA1、HMAC-SHA256、HMAC-SHA384、HMAC-SHA512 の結果が即座に生成されます（利用先のシステムが大文字を想定している場合は「Uppercase output」にチェックを入れてください）。
4. 必要な HMAC の横にある「Copy」をクリックします。

例

入力

Secret Key: key
Message: The quick brown fox jumps over the lazy dog

出力

HMAC-SHA256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA1: de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9

これは公開されている標準的なテストベクタです。鍵に「key」、メッセージにこの文字列を使えば、正しく実装されたどのツールでも HMAC-SHA256 と HMAC-SHA1 は必ずこの値になるため、本ツールの出力を独立に検証できます。

HMACと単なるハッシュ：鍵が必要になるのはどんなときか

判断基準となるのは、「このダイジェストを誰が作成したかを証明する必要があるのか、それとも内容が変化していないことだけを確認できればよいのか」という点です。ダウンロードしたファイルが公開元のリストと一致するかを確認する、レコードの重複を排除するといった、公開のチェックサムで十分な用途であれば、単なるハッシュで問題なく、鍵なしで誰でも検証できます。一方、特定の秘密鍵を保持する者だけがそのダイジェストを作成できることを証明する必要がある場合——API 呼び出し元の認証、Webhook 送信元の信頼確認など——には HMAC が必要です。単なるハッシュでは、秘密を持たない攻撃者でも正規の送信者と同じように有効なダイジェストを偽造できてしまうからです。

→ マルチアルゴリズム ハッシュジェネレーター · JWTデコーダー · MD5ジェネレーター

4つのHMACアルゴリズムの比較

4つとも RFC 2104 で定義された同じ HMAC の構成を使っており、違いは基盤となるハッシュ関数、つまり出力長だけです。

よくある使い方

• 共有秘密で送信APIリクエストに署名し、サーバー側が呼び出し元の身元を検証できるようにする。
• 受信したWebhookペイロードを検証する（Stripe-Signature、GitHub の X-Hub-Signature-256 などのヘッダーはいずれも HMAC-SHA256 を使用）。
• HS256/HS384/HS512 で署名された JWT の署名部分を生成・検証する。
• デプロイ前に、サーバー側またはクライアント側の HMAC 実装が期待する出力と一致するかをテストする。

Webhook署名を検証する際の注意点

多くのサービスは、署名対象の文字列としてリクエストボディをそのまま使うわけではなく、タイムスタンプなど他の要素と連結した文字列に対してHMACを計算します。たとえばStripeはタイムスタンプとペイロードを特定のフォーマットで結合してから署名するため、このツールで再現検証する際は、実際に送信元がどの文字列に対して署名しているのかをそのサービスのドキュメントで確認する必要があります。

また、リクエストボディがJSONの場合、パース後に再シリアライズすると改行やキーの順序が変わり、元のバイト列と一致しなくなることがよくあります。検証時は必ず「受信した生のリクエストボディ」をそのままメッセージ欄に貼り付けてください――パース・整形後の文字列を使うと、正しい実装でも一致しない結果になります。

よくある質問