tigtools

HMAC 產生器

使用訊息和密鑰計算訊息驗證碼（HMAC），或驗證收到的簽章。密鑰和訊息只會留在您的瀏覽器中。

在瀏覽器中執行 免註冊

密鑰和訊息只會在這個瀏覽器分頁中處理，不會傳送到任何地方。不過，請避免在共用或不受信任的電腦上貼上正式環境的密鑰。
密鑰格式

會將您輸入的內容原樣以 UTF-8 簽署。結尾多一個空格或換行都會改變結果。

輸出格式

貼上十六進位（大小寫不限）或 Base64 格式的簽章，與上方結果比對。

使用方式

  1. 輸入密鑰，並選擇密鑰是純文字還是十六進位位元組。
  2. 貼上訊息，例如收到的 webhook payload，內容需與收到時完全一致。
  3. 選擇服務使用的演算法和輸出編碼；輸入時會即時更新 HMAC。
  4. 若要驗證簽章，請貼到驗證欄位，並確認結果顯示「相符」。

運作方式

HMAC（RFC 2104）會結合密鑰和雜湊函式來產生簽章，只有持有密鑰的人才能建立簽章。Webhook 和簽署 API 請求等服務會在每則訊息中附上 HMAC，讓接收方確認訊息來源可信且未遭修改。

此工具使用瀏覽器的 Web Crypto API（crypto.subtle.importKey 和 sign），並以 RFC 4231 和 RFC 2202 測試向量進行驗證。文字格式的密鑰和訊息會以 UTF-8 編碼。十六進位密鑰會解碼為原始位元組；空格、冒號和開頭的 0x 會忽略。HMAC-SHA-256 是最常見的選擇；HMAC-SHA-1 作為 MAC 仍被視為安全，但主要用於較舊的 API。

如果簽章不符，請檢查以下最常見的差異：訊息的實際位元組內容（許多 webhook 提供者會對原始本文簽章，而非重新格式化的 JSON）、提供者加到簽署字串中的時間戳記或前置字串、密鑰是直接當作文字使用，還是必須先從十六進位或 Base64 解碼，以及預期簽章使用十六進位還是 Base64，並確認是否帶有 “sha256=” 之類的前置字串；比對前應先移除該字串。

範例

RFC 4231 測試案例

密鑰為文字 “Jefe”、訊息為 “what do ya want for nothing?” 時，HMAC-SHA-256 的結果為 5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843。使用「試用範例」載入內容。

驗證 webhook 簽章

提供者會在每個請求中傳送 X-Signature: sha256=… 標頭。將原始請求本文貼為訊息，將 webhook 密鑰設為密鑰，選擇 HMAC-SHA-256 和 Hex，然後將 “sha256=” 後面的值貼到驗證欄位。

十六進位編碼的密鑰

有些系統會提供十六進位字串格式的密鑰，例如 0b0b0b…。請將密鑰格式選為 Hex，讓工具使用解碼後的位元組進行簽章；若將相同字串當作文字使用，結果會完全不同。

常見問題

HMAC 和一般雜湊有什麼不同？

任何人都能計算訊息的一般雜湊值，例如 SHA-256。HMAC 也會使用密鑰，因此只有持有密鑰的人才能產生或驗證 HMAC。這能證明訊息來自持有密鑰的人，且未遭修改。

為什麼我的 HMAC 和伺服器產生的不一致？

輸入的位元組內容幾乎總是有所不同，可能是換行格式、空白字元、JSON 鍵順序、字元編碼，或是應從十六進位或 Base64 解碼的密鑰。另外，請確認使用相同的編碼格式（十六進位或 Base64），並移除 “sha256=” 之類的前置字串。

我的密鑰會傳送到其他地方嗎？

不會。密鑰和訊息只會由此瀏覽器分頁中的 Web Crypto API 使用，不會上傳、儲存或納入分析資料。

HMAC-SHA-1 目前仍安全嗎？

SHA-1 碰撞不會直接破壞 HMAC-SHA-1 的安全性，而且為了相容性，目前仍可使用。新系統請使用 HMAC-SHA-256 或更強的演算法。

隱私權

密鑰、訊息和結果只會存在這個瀏覽器分頁中，不會上傳、儲存或傳送至分析服務；系統只會記錄一筆匿名的工具使用事件。