HMAC ジェネレーターとは？
HMACジェネレーターは、秘密鍵とハッシュアルゴリズム（SHA-256、SHA-512など）を使用してキー付きハッシュメッセージ認証コードを生成します。HMACはデータの整合性と真正性の両方を検証するために使用され、API認証、Webフック署名、JWTトークンで広く活用されています。
HMACは秘密鍵をハッシュに混ぜ込むため、その鍵を知る人だけが署名を検証できます。SHA-1・SHA-256・SHA-384・SHA-512に対応し、出力は16進数・Base64・Base64URL・生バイナリから選べます。さらに GitHub・Stripe・Slack・Shopify の Webhook 向けワンクリックプリセットがあり、正しいアルゴリズムとヘッダー接頭辞を自動で入力します。メッセージはプレーンテキストとして入力するほか、16進数・Base64・Base64URL でエンコード済みのまま貼り付けることもでき、署名前に生のバイトへデコードされます。ライブのバイト数表示が、本番で安全な32バイト未満の鍵を知らせ、入力に合わせて署名はその場で再計算され、検証欄はこれらのプロバイダーが送る sha256= や v0= の接頭辞も許容します。メッセージも鍵もお使いの端末内で処理されます。
使い方
- ステップ1 — メッセージと秘密鍵を入力します。
- ステップ2 — Webhook プリセット（GitHub、Stripe、Slack、Shopify）を選ぶか、ハッシュアルゴリズム（SHA-1、SHA-256、SHA-384、SHA-512）と出力エンコーディング（16進数、Base64、Base64URL、バイナリ）を自分で設定します。エンコード済みのペイロードを貼り付けるには、メッセージ入力を16進数または Base64 に切り替えてください。
- ステップ3 — 生成されたHMAC署名をコピーして、APIヘッダーやWebフック検証に使用します。
使用するタイミング
- Webhookペイロードに署名し、受信側が送信元と非改ざんを検証できるようにするとき。
- AWS Signature Version 4などのAPI認証スキーム用にリクエスト署名を生成するとき。
- HS256・HS384・HS512アルゴリズムでJWT署名を作成するとき。
結果
決済APIがHMAC-SHA256署名付きリクエストを要求しています。リクエスト本文をメッセージとして、APIシークレットをキーとして入力し、生成された署名をX-Signatureヘッダーにコピーします。
よくある質問
- HMACとSHA-256で「メッセージ+鍵」を単に計算するのとは何が違う？
- HMACは内外のパディング付き鍵を用いた特殊な二重ハッシュ構造です。これによりSHA-1やSHA-256に対する長さ拡張攻撃を防げます。素朴なhash(key‖message)構成では防げません。
- 出力はhexとBase64のどちらを使う？
- APIやWebhook側の指定に合わせます。HTTPヘッダではhexが多く（Stripe・GitHub）、JSONボディやJWTではBase64が多いです。署名そのものは同じで、エンコードだけが異なります。
- 秘密鍵はどれくらいの長さが必要？
- 少なくとも32バイト（256ビット）の乱数で、できれば暗号学的乱数源から生成します。短いと安全性が落ちます。ハッシュのブロックサイズ（SHA-256は64バイト）より長くしてもHMAC内部で圧縮されるため意味はありません。
- APIから受け取った署名と自分の計算結果が違うのはなぜ？
- ほぼ署名対象の中身がずれているのが原因です。空白、改行コード、クエリパラメータの順序、URLエンコード、タイムスタンプの有無まですべて影響します。プロバイダーのレシピをバイト単位で正確に再現してください。
- HMAC-SHA1は今でも安全？
- 新規システムではHMAC-SHA256以上を選んでください。HMAC自体は衝突耐性に依存しないため技術的にはHMAC-SHA1も安全ですが、長期的にはSHA-1から完全に離れるのが無難な選択です。