HMAC ジェネレーター

HMAC とは？#

HMAC は Hash-based Message Authentication Code（ハッシュベースのメッセージ認証コード）の略です。通常のハッシュ（SHA-256 など）は「このバイト列は変わったか？」という問いに答えます。HMAC はより強い問いに答えます——「このバイト列は変わったか、かつ、私の秘密鍵を本当に共有している誰かが送ったか？」。この違いは、完全には信頼できない経路をメッセージが移動するとき——ウェブフックのコールバック、署名付き URL、API リクエストの署名、サービス間トークン——に重要になります。

機械的に言えば、HMAC は秘密鍵を定義された方法（パディングを伴う 2 ラウンド）でハッシュ関数に混ぜ込み、鍵なしでは偽造できないようにします。出力は固定長のバイト列で、そのサイズは元のハッシュに一致します: SHA-1 なら 20 バイト、SHA-256 なら 32、SHA-384 なら 48、SHA-512 なら 64 です。

このページは Web Crypto API を使ってブラウザ内で HMAC を計算します。ハッシュを選び、メッセージと秘密を貼り付け、Hex または Base64 のダイジェストを得ます。

使い方#

1. メッセージに入力または貼り付けます——認証したいペイロードです。これが相手側でハッシュされるバイトです。
2. 秘密鍵を入力します。このフィールドは既定でマスクされており、入力中に表示するには右の目のアイコンをクリックします。鍵もメッセージも UTF-8 としてエンコードされます。
3. アルゴリズムを選びます:
   • SHA-1 — 160 ビット。高速ですが、レガシーの HMAC にのみ適しています（一部の古い署名フローでは依然として必須です）。デジタル署名に SHA-1 を使わないでください。
   • SHA-256 — 256 ビット。モダンな既定値です。ウェブフック署名の圧倒的多数（Stripe、GitHub、Slack 系のフロー）が HMAC-SHA-256 を使います。
   • SHA-384 / SHA-512 — より長いダイジェスト、わずかに高い衝突耐性、やや遅い。受信系が明示的に要求するときに選びます。
4. 出力エンコードを選びます: Hex（X-Signature 系ヘッダーで典型的）または Base64（ダイジェストが JSON やトークンに埋め込まれる場合に典型）。
5. 生成をクリックします。ダイジェストが右ペインに現れ、ステータス行がアルゴリズムとバイト長を妥当性チェックとして示します。コピーで取り出します。

主な特徴#

• Web Crypto 基盤。 ブラウザのネイティブ crypto.subtle——本番コードが使うのと同じプリミティブ——を使い、JavaScript の再実装ではありません。
• 長さの妥当性チェック。 すべてのダイジェストがそのアルゴリズムに期待されるバイト長に対して検証されるため、切り詰めや改ざんされた結果が黙ってすり抜けることはありません。
• Hex または Base64 出力。 1 クリックで切替、再入力なし。
• 秘密はローカルに留まる。 鍵フィールドはパスワード入力として描画され、ページから外に出ることはありません——バックエンドはありません。
• セキュアコンテキスト対応。 ページが普通の HTTP で読み込まれたことがあれば crypto.subtle は利用できず、ツールは間違った答えを出すのではなく、その旨を明示的に報告します。

実例#

古典的な参照ペア（RFC 4231）は鍵 Jefe、メッセージ what do ya want for nothing? を使います。このページを SHA-256 と Hex に設定すると、ダイジェストは次のとおりです:

5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843

同じ入力で SHA-512 に切り替えると、ダイジェストは長さが倍になります:

164b7a7bfcf819e2e395fbe73b56e0a387bd64222e831fd610270cd7ea2505549758bf75c05a994a6d034f65f8f0e6fdcaeab1a34d4a6b4b636e070a38bce737

どちらもここで再現できます: サンプルを読み込み、生成します。このペアは、このツール自身のテストスイートが正確性を検証するのにも使います——もし異なるダイジェストが出たなら、ページが何者かによって改ざんされています。

よくある質問#

SHA-256 と SHA-512 のどちらを使うべきですか？#

HMAC に限って言えば、SHA-256 が実用的な既定値です: 主要なウェブフック署名器はすべてそれを使い、高速で、256 ビットのダイジェストはすでに総当たりの領域を遥かに超えています。SHA-512 に移るのは、(a) 受信系がそれを要求する場合、または (b) ゼロから新しいプロトコルを設計し、控えめな速度コストで余分の衝突マージンを欲する場合だけです。それを必須とするレガシーシステムに合わせるのでなければ、SHA-1 は完全に避けてください。

HMAC はメッセージを暗号化するのと同じですか？#

いいえ。HMAC は認証しかしません——メッセージが改変されず、鍵を持つ誰かから来たことを証明します。メッセージ自体は平文のままです。機密性も必要なら、HMAC を暗号方式と組み合わせるか、AES-GCM のような認証付き暗号モードを使ってください。

秘密鍵はダイジェストから復元できますか？#

いいえ。ダイジェストはメッセージと鍵の両方の一方向関数であり、出力から鍵を復元するのは計算上実行不可能です。とはいえ、短い、あるいは推測可能な鍵は、オフラインで候補鍵を試すことで総当たりされ得るため——人間が選んだパスワードではなく、少なくとも 128 ビットの実際のエントロピーを持つ鍵を使ってください。

受信側が署名が一致しないと言います。最初に何を確認すべきですか？#

十中八九、メッセージのバイト表現です: 末尾の改行、URL エンコード対生ボディ、JSON の空白、異なるフィールド順序。他を確認する前に、あなたが署名したバイトと受信側がハッシュしたバイトを、文字ごとに比較してください。