HMAC生成ツール（SHA-256、SHA-512）
プライバシー優先設計 — すべてブラウザ内で処理します
メッセージと秘密鍵からHMAC-SHA256（またはSHA-1、SHA-512）の署名をブラウザ内で生成します。Webhookペイロード、APIリクエスト、両者が秘密鍵を共有して真正性を検証する任意のフローの署名に最適です。
HMACの用途
HMACは共有された秘密鍵とメッセージから固定長の署名を作ります。秘密鍵を共有する受信者は、HMACを再計算してバイト単位で比較できます。署名が一致すれば、メッセージは真正で改ざんされていないことが分かります。Stripe、GitHub、Slack、そしてほとんどのWebhookシステムは、受信者が発信元を信頼できるよう、HMAC-SHA256でペイロードを署名しています。
アルゴリズムとエンコーディングのオプション
ToovaはHMAC-SHA256、HMAC-SHA1、HMAC-SHA512に対応しています。SHA-256が現代の既定値です。連携先サービスのドキュメントに合わせてアルゴリズムを選んでください。出力は既定で16進、Base64とBase64-URLも選択可能です。Webhookプロバイダーは特定の形式を要求することが多いため、トグルを切り替える前にドキュメントを確認してください。
ローカルのみの署名
署名はすべてブラウザ内で計算されます。メッセージと秘密鍵がページから外に出ることはありません。秘密鍵さえあれば誰でも有効な署名を偽造できるため、これが重要です。サードパーティのフォームに鍵を漏らせばシステムが侵害されます。Toovaは本番Webhookのデバッグ、署名の検証、API連携の調査に安全に使えます。
よくある質問
- HMACと普通のハッシュの違いは何ですか？
- 普通のハッシュは任意の入力に対して決定的で、誰でも計算できます。HMACは秘密鍵を混ぜ込むため、鍵を持つ当事者だけが一致する署名を生成できます。これがHMACを認証に使える理由であり、普通のハッシュは完全性チェック以外には適しません。
- どのアルゴリズムを選ぶべきですか？
- 連携先サービスが明示的に他を要求しない限り、HMAC-SHA256を使ってください。SHA-1は古いシステムで依然として一般的ですが、新規設計では使うべきではありません。SHA-512は多くの用途で過剰ですが、より保守的な選択です。
- 鍵は文字列とバイト列のどちらにすべきですか？
- HMACはバイト列を受け取ります。Toovaは既定で鍵をUTF-8テキストとして扱います。これは多くのAPIの動作と一致します。仕様に「hexエンコードされたシークレット」とある場合、鍵エンコードトグルを切り替えて、サービスが期待する通りのバイト列にしてください。
- 秘密鍵はサーバーへ送信されますか？
- いいえ。署名はすべてブラウザ内で行われます。秘密鍵とメッセージが端末から外に出ることはなく、署名中にNetworkタブは空のままです。
- 署名がサービスの期待と一致しないのはなぜですか？
- 最もよくある原因はエンコーディングの不一致（16進かBase64か）、ペイロードの末尾改行、アルゴリズム違いです。サービスのドキュメントと3点をすべて完全に一致させてください。