HMAC ジェネレーター＆署名検証ツール

HMAC とは？

const crypto = require('crypto');

// HMAC-SHA256 with a UTF-8 text key, hex output
const hmac = crypto
  .createHmac('sha256', 'my-secret-key')
  .update('Hello, World!')
  .digest('hex');

console.log(hmac);
// → 'cf3141611e22ea26a9cac6fe41d941274dd6653622c83cba13972d177bd69699'

// Verify a signature in constant time
function verify(message, key, expectedHex) {
  const actual = crypto.createHmac('sha256', key).update(message).digest();
  const expected = Buffer.from(expectedHex, 'hex');
  return actual.length === expected.length &&
    crypto.timingSafeEqual(actual, expected);
}

主な機能

HMAC の例

Hello, World!

cf3141611e22ea26a9cac6fe41d941274dd6653622c83cba13972d177bd69699

{"id":42,"event":"user.created"}

Cd2f7zTKaJFeG6k+t1FcvDPn51OAZ2f4GrxkCUgMhGs=

what do ya want for nothing?

5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843

The quick brown fox

36f44b125a8a90639dc46733039571792e081e0fd8685ff746784b02ed14aa35629d562c7117cde4a701570551faa5a5e1b7ef1eb5c3bcd4cc1fdb8923fcf14e

HMAC を生成・検証する方法

1. 1

   アルゴリズムを選ぶ

   HMAC-SHA256（デフォルトで、ほぼすべての webhook、API、JWT に適した選択）を選ぶか、それを必要とするシステムに合わせて SHA-1、SHA-384、SHA-512 に切り替えます。4 つすべてが Web Crypto API を介してブラウザ内でネイティブに動作します。

2. 2

   秘密鍵を入力しエンコーディングを設定する

   秘密鍵を入力または貼り付け、サーバーの解釈方法に合わせて「鍵のエンコーディング」を設定します：普通の文字列なら Text（UTF-8）、16 進のバイト列なら Hex、base64 のシークレットなら Base64 です。これを誤ることは HMAC 不一致の最大の原因なので、迷ったら 3 つすべて試してください。

3. 3

   メッセージを入力する

   署名したい正確なバイト列を貼り付けます —— webhook の場合は、再シリアライズや空白の変更を一切行わない、バイト単位で生のリクエストボディです。HMAC は編集に応じてその場で再計算され、サーバーには何も送信されません。

4. 4

   出力フォーマットを選んでコピーする

   Hex（GitHub 形式）、Base64（Stripe/AWS 形式）、Base64URL（JWT 形式）から、連携先が期待するものに合わせて選び、「コピー」をクリックして署名を取得します。

5. 5

   既存の署名を検証する

   「検証」タブに切り替え、ヘッダーやトークンから「期待される HMAC」を貼り付けると、ツールが計算した署名が一致するかを定数時間で確認します —— こうしてペイロードに対して行動を起こす前に認証できます。

よくある HMAC の間違い

// Server stored a base64 secret but you sign the literal string
createHmac('sha256', 'c2VjcmV0LWtleQ==').update(msg)

// Decode the base64 secret to raw bytes first
createHmac('sha256', Buffer.from('c2VjcmV0LWtleQ==', 'base64')).update(msg)

// Provider sends base64, you compare hex
expected = 'Cd2f7z...=' // base64
actual   = digest('hex') // hex — never matches

// Produce the same encoding the provider uses
actual = digest('base64')

// Re-serialization changes the bytes
body = JSON.stringify(JSON.parse(rawBody))
verify(hmac(body))

// Sign the raw bytes exactly as received
verify(hmac(rawBody))

if (received === computed) { /* trust */ }

if (crypto.timingSafeEqual(receivedBuf, computedBuf)) { /* trust */ }

HMAC の用途

webhook 署名を検証する

GitHub、Stripe、Slack、Twilio などのプロバイダーは、あなたとだけ共有する秘密鍵でリクエストボディに対する HMAC を使って各 webhook に署名します。タグを再計算してヘッダー（例：X-Hub-Signature-256）と比較し、行動を起こす前にイベントが本物だと確認します。「検証」タブを使えば使い捨てコードを書かずに行えます。

API リクエストに署名する

認証付きの API では、シークレット自体を送る代わりに、共有シークレットでリクエスト（メソッド、パス、タイムスタンプ、ボディ）を HMAC 署名するようクライアントに求めることがよくあります。AWS Signature Version 4 が代表例です。本ツールはそれらの署名を一歩ずつ再現・デバッグできます。

メッセージの完全性を保証する

サービス間でトークン、cookie、メッセージを渡す際に HMAC を付与すると、受信側はあらゆる改ざんを検出できます。タグはシークレットに依存するため、攻撃者はデータを変更した後にそれを再計算できません —— 普通のチェックサムとは異なります。

JWT の HS256 署名を理解する

HS256 で署名された JWT は base64url(header) + '.' + base64url(payload) を HMAC-SHA256 で署名し、結果を Base64URL で出力したものに過ぎません。ここでアルゴリズムを SHA-256、出力を Base64URL に設定すると、その署名がどう生成されるかを正確に確認でき、JWT エンコーダーでクロスチェックできます。

一致しない署名をデバッグする

HMAC がサーバーのものと一致しないとき、本ツールは原因を切り分ける最速の方法です：鍵を Text、Hex、Base64 で試し、出力を Hex と Base64 で切り替え、署名しているのが正確な生のバイト列であることを確認します —— すべてコードを再デプロイせずに行えます。

HMAC の仕組み

RFC 2104 構造

HMAC は H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ m)) と定義されます。ここで ipad は繰り返されたバイト 0x36、opad は繰り返された 0x5c で、いずれもハッシュのブロックサイズまで埋められます。ブロックサイズより長い鍵はまずハッシュされ、短い鍵はゼロ埋めされます。この 2 パスのネストこそが HMAC の安全性証明を与えており、基盤ハッシュが衝突耐性を持たなくても成立します。

鍵付きハッシュが普通のハッシュに勝る理由

普通のハッシュはデータが偶発的に破損していないことしか証明しません。誰でも任意のメッセージ（改ざんされたものを含む）に対して再計算できるからです。HMAC はシークレットを混ぜ込むため、鍵を持つ者だけが有効なタグを生成できます。これは完全性のみを完全性と真正性に変えるものであり、webhook や署名付きリクエストが実際に必要とする性質です。

長さ拡張への耐性

裸の SHA-1、SHA-256、SHA-512 は Merkle–Damgård ハッシュで、長さ拡張に対して脆弱です：H(secret ‖ msg) が与えられると、攻撃者はシークレットを知らずに H(secret ‖ msg ‖ extra) を計算できます。素朴な「シークレットプレフィックス MAC」方式はこれで破られます。HMAC の外側のハッシュがこの攻撃を無力化します。これがシークレットとメッセージを一緒にハッシュするのではなく HMAC を使う主な理由です。

SHA-256 と SHA-512 の選択

HMAC-SHA256 は 256 ビット（64 hex 文字）のタグを生成し、相互運用のデフォルトです —— 高速、普遍的、どこでもサポートされています。HMAC-SHA512 は 512 ビット（128 hex 文字）のタグを生成し、SHA-512 が 64 ビットワードを使うため 64 ビット CPU ではしばしば高速です。仕様や対向システムが SHA-512 を要求しない限り SHA-256 を選んでください。どちらも認証には安全です。

Web Crypto 実装

本ツールは crypto.subtle.importKey を呼んで鍵を読み込み（Text、Hex、Base64 からデコード）、crypto.subtle.sign('HMAC', ...) でタグを計算し、生のバイト列を Hex、Base64、Base64URL にエンコードします。これはブラウザが TLS に使うのと同じネイティブで監査済みの実装で、速度のため JavaScript エンジンの外で動作します。

HMAC のベストプラクティス

鍵はハッシュ出力以上の長さにする

HMAC-SHA256 には少なくとも 32 バイト（256 ビット）のランダムなシークレットを、SHA-512 には 64 バイトを使います。短いまたは低エントロピーの鍵は最も弱い環です。鍵は暗号学的に安全な乱数源から生成してください —— 決してパスワードや予測可能な文字列を使わないでください。

タグは常に定数時間で比較する

署名は == や文字列の等価ではなく、定数時間比較（Node なら crypto.timingSafeEqual、Python なら hmac.compare_digest）で検証します。素朴な比較は最初の異なるバイトで早期に返り、攻撃者が有効なタグをバイト単位で復元できるタイミングを漏らします。本ツールの「検証」タブはすでに定数時間で比較しています。

秘密鍵を決してログ出力・露出しない

署名シークレットをログ、エラーメッセージ、URL、クライアントサイドコードから締め出してください。シークレットマネージャーや環境変数に保存し、定期的にローテーションし、各連携をそれぞれの鍵にスコープすることで、1 つの漏洩がすべてを危険にさらさないようにします。

HMAC-SHA256 以上を優先する

デフォルトは HMAC-SHA256 とし、対向が要求する場合は SHA-384 や SHA-512 に上げます。新しいシステムで HMAC-SHA1 は避け、HMAC-MD5 は決して使わないでください。HMAC は裸の署名より弱いハッシュを許容しますが、現代のハッシュから始めることで最大の余裕が得られます。

タイムスタンプを含む正確なバイトに署名する

生の未改変のペイロードに署名します —— JSON の再シリアライズや空白の除去はバイトを変え、検証を壊します。リクエスト署名では、署名対象データにタイムスタンプや nonce を含め、古い署名を拒否してリプレイ攻撃を防ぎます。

HMAC のよくある質問