HMAC 計算工具會根據一組共用密鑰與一段精確訊息，計算出鍵控雜湊訊息鑑別碼，並回傳固定長度的雜湊標籤(以十六進位或 Base64 表示)。持有同一把密鑰的驗證端可以重新計算該標籤，以確認訊息在傳輸過程中沒有遭到竄改。該工具結合了密碼學雜湊函式(通常是 SHA-256、SHA-384 或 SHA-512)與同一把密鑰兩次——一次在雜湊壓縮函式內，一次在雜湊壓縮函式外——因此即便攻擊者能讀取訊息，只要沒有密鑰，就無法偽造出有效的標籤。HMAC 計算工具「不會」做的事是隱藏訊息內容:它只負責鑑別位元組的完整性，並不對其加密。一個可靠的瀏覽器端 HMAC 計算工具，例如 HMAC Generator，讓你選擇雜湊演算法，將密鑰與訊息以 UTF-8 文字或原始十六進位位元組貼上，然後在不將輸入內容送至遠端伺服器的情況下複製產生的標籤。
人們搜尋 HMAC 計算工具的原因，通常落在以下三種任務之一:為外送 API 請求簽章、驗證傳入的 Webhook 酬載，或是在開發過程中重現一份已公開的測試向量。這三種任務都有同一個核心需求——必須與通訊協定的精確位元組及所選演算法完全一致——但各自潛藏不同的陷阱。下列章節將說明計算工具會產出什麼、如何在 SHA-256、SHA-384 與 SHA-512 之間做選擇、逐步的操作流程，以及決定兩台計算工具是否會算出相同標籤的編碼與安全性細節。
HMAC 計算工具會回傳什麼
所有 HMAC 計算工具都執行 RFC 4231 與 Web Cryptography API 所定義的同一套數學構造。你提供一把密鑰與一段訊息;工具會將密鑰填充至雜湊的區塊大小，將其與內部常數做 XOR，再與訊息一起雜湊;接著將密鑰與外部常數做 XOR，然後對該組合再做一次雜湊。最終輸出的標籤長度固定，完全由所選的雜湊函式決定。
任何正確的 HMAC 計算工具都具備以下三項特性:
- 標籤長度僅取決於雜湊演算法:SHA-256 產生 32 位元組，SHA-384 產生 48 位元組，SHA-512 產生 64 位元組。
- 相同的密鑰、相同的訊息位元組、相同的雜湊演算法，無論由哪一台計算工具運算，都會產生相同的標籤。
- 標籤本身不會洩漏任何訊息內容;它只能證明持有密鑰的一方確實看過那些精確的位元組。
計算工具會將原始位元組格式化為小寫十六進位或標準填補式 Base64 以便顯示。這兩種表示法描述的是同一組位元組——十六進位字串並不會比 Base64「更安全」或「更相容」，一切端看通訊協定指定要哪一種。HMAC Generator 同時提供這兩種格式，讓你能依用戶端或伺服器所需複製對應的輸出。
在 HMAC 中比較 SHA-256、SHA-384 與 SHA-512
雜湊演算法的選擇，是影響計算工具輸出結果最關鍵的因素。指名 HMAC-SHA-256 的規格無法用 SHA-384 來滿足，反之亦然，因為兩者的標籤長度不同，驗證勢必失敗。請參考下表，將計算工具所提供的三種選項對應到其公開的特性。若需要更深入地逐一示範如何用這些雜湊產生標籤，請參閱 HMAC-SHA-256、SHA-384 與 SHA-512 產生指南。
| 雜湊演算法 | 標籤長度(位元組) | 十六進位字元數 | 標準 Base64 長度 | 常見用途 |
|---|---|---|---|---|
| SHA-256 | 32 | 64 | 44 | REST API 請求簽章、Stripe 風格的 Webhook 標頭、JWT HS256 |
| SHA-384 | 48 | 96 | 64 | 明確指定 SHA-384 之通訊協定的高保證度變體 |
| SHA-512 | 64 | 128 | 88 | JWT HS512、長標籤的通訊協定、需要對齊 64 位元字邊界的環境 |
這些是 NIST FIPS 198-1 與 SHA-2 系列規格所定義的固定數值，並非運算出來的結果。這些數字不會因為計算工具不同而改變，因為底層的雜湊完全相同。若相同雜湊的公開測試向量與計算工具的結果不一致，差異必定出在密鑰位元組或訊息位元組，絕對不是雜湊運算本身出了問題。
依據密鑰與訊息計算 HMAC
下列流程對應 HMAC Generator 已驗證過的操作步驟，並適用於大多數其他計算工具。請依序執行，確保每一項輸入在產生標籤之前都已確定無誤。
- 確認通訊協定明確指定的雜湊演算法——SHA-256、SHA-384 或 SHA-512——並確認它要求的是完整的 HMAC 標籤，而不是截斷的前綴或預先雜湊過的訊息。
- 針對密鑰與訊息，各自獨立選擇 UTF-8 或十六進位輸入。多數規格將密鑰視為原始位元組、將訊息視為文字，但 HMAC Generator 對兩者各自提供了獨立的選擇器。
- 貼上精確的位元組，不要加上額外的格式:不加 0x 前綴、不加空格、不加冒號，除非規格明定必須包含，否則也不要附加結尾換行。HMAC Generator 會拒絕空密鑰與空訊息，以防止誤點而產出無意義的標籤。
- 產生標籤後，依通訊協定指定複製十六進位或標準 Base64 格式的結果。唯有在規格明確要求時，才可進行轉換或截斷——絕對不要憑肉眼自行處理。
- 在驗證端以相同的雜湊、相同的密鑰與相同的訊息位元組重新計算標籤。若結果相符，即可確認訊息未遭竄改，且送出端確實持有該密鑰。
若要以已知答案驗證計算工具，請執行 RFC 4231 測試案例 1:密鑰 = 0x0b 重複 20 次，訊息 = ASCII 字串 Hi There，雜湊演算法 = SHA-256。預期的 HMAC-SHA-256 標籤為 b0344c61d8db38535ca8afceaf0bf12b 881dc200c9833da726e9376c2e32cff7。HMAC Generator 會回傳相同的 64 字元小寫十六進位字串，證明其與 RFC 的參考實作一致。
為什麼兩台 HMAC 計算工具會算出不同結果
若兩台計算工具在看似相同的輸入下產生不同的標籤，代表兩者的輸入實際上並不相同。整合工作中最常見的不一致來源，大致依發生順序排列如下:
- 雜湊演算法不一致。 SHA-256 與 SHA-384 會產生不同長度與不同位元組值的標籤;設定為其中一種的驗證端必然會拒絕另一種。
- 密鑰編碼漂移。 以文字形式貼上的密鑰會在計算工具內部被編碼為 UTF-8 位元組，而以十六進位貼上的密鑰則被視為原始位元組。一個 32 字元的 ASCII 字串，與其 64 字元的十六進位表示，描述的是完全不同的密鑰。
- 訊息中的空白字元。 結尾換行、歸位字元或結尾空格，都屬於訊息的一部分。兩個以不同方式序列化 JSON 的系統，雜湊出來的位元組流也會不同。
- 標籤截斷或前置加工。 部分通訊協定只取標籤的前 N 個位元組、在前面加上演算法識別符，或將其包裝在結構化封套中。計算工具輸出的是完整的原始標籤;任何進一步的轉換都應由協定規則負責。
- Base64 變體差異。 標準填補式 Base64、Base64url(使用 - 與 _)，以及無填補的原始 Base64，三者不可互換。HMAC Generator 輸出的是含填補的標準 Base64;若驗證端預期的是 Base64url，則需要額外的轉換步驟。
每當標籤比對失敗時，請從這份清單由上而下逐項檢查，而不要先質疑計算工具本身。HMAC Generator 將雜湊演算法、密鑰編碼與訊息編碼都設為可見的輸入欄位，正是為了讓任何差異都能一目了然。
密鑰與訊息的編碼選擇
計算工具為每個欄位提供兩種輸入方式，選錯往往是握手失敗最常見的原因。文字模式會將字串編碼為 UTF-8，因此含變音符號的字母、CJK 字元與表情符號，各自會展開為兩個、三個或四個位元組。以文字模式貼上「café」這個詞，會得到 5 個位元組(c、a、f，接著 0xC3 0xA9);同樣的字詞若以十六進位字串 636166C3A9 輸入，得到的也是相同的 5 個位元組。
十六進位模式較為嚴格:只接受偶數個十六進位數字，並精確保留每一個位元組，包括文字模式無法表示的零位元組。十六進位模式會拒絕前綴、空格、冒號與奇數的半位元組，以避免任何遺漏的格式字元悄悄改變通訊協定的值。對於公開的測試向量與二進位通訊協定欄位——例如訊息摘要、擷取自封包的請求主體、以原始位元組形式傳遞的簽章密鑰——十六進位模式是更安全的選擇。
文字模式適用於規格將訊息定義為字元字串、且密鑰為各方皆以相同方式輸入的通關語的情形。請注意，單純的人類密碼很少是強度足夠的 HMAC 密鑰;通訊協定應指定一個基於密碼的金鑰衍生函式，並提供 salt 與迭代次數等參數，或者應透過受保護的通道分發一把高熵的隨機密鑰。
將計算工具用於 API 簽章與 Webhook
兩項實務工作是計算工具的主要使用情境。第一是為外送 API 請求簽章:用戶端將規範化的請求字串串接起來，以共用密鑰簽署，再將標籤放入標頭送出。第二是驗證傳入的 Webhook:伺服器收到酬載後，以原始請求主體重新計算標籤，並與送出端提供的值進行比對。
在簽章方面，計算工具扮演的是規範化字串的運算引擎:依規格建構出精確的字串，將其作為訊息貼上，將密鑰作為密鑰貼上，然後把產生的標籤複製到標頭中。若 API 拒絕該簽章，不一致之處幾乎都能追溯到規範化字串本身——換行字元、查詢參數的順序、包含或排除的標頭——而不是 HMAC 運算出了問題。
在 Webhook 驗證方面，計算工具是除錯輔助工具:貼上密鑰與原始請求主體，產生預期的標籤，並與簽章標頭中的值逐字元比對。HMAC Generator 將每個解碼後的欄位限制為 1,000,000 位元組，這限制了可貼上的原始 Webhook 酬載大小。伺服器端務必使用常數時間比較，以免比對過程本身洩漏時序資訊。計算工具負責數學運算;通訊協定則負責封裝處理。
影響計算結果的安全性實務
三項操作習慣會改變計算結果，省略這些步驟會讓一個正確的標籤變得毫無用處：
- 產生高熵的金鑰。透過受保護通道傳遞的、長度正確的獨立隨機位元組，是唯一持久的秘密。重用、從脈絡衍生或人為選擇的金鑰，會讓 HMAC 偽造比雜湊強度所暗示的更容易。
- 依用途區分金鑰。用於簽署 webhook 承載的金鑰不應與用於簽署使用者 session 權杖的金鑰相同。如果某個用途遭到洩露，另一個仍保持完整，且輪替作業只在本地進行。
- 在洩露後進行輪替並於伺服器上驗證。當金鑰變更時，使用新金鑰產生一個新的計算標籤，並讓驗證者使用常數時間函式重新計算並進行比較。以程式碼進行比較，而非以人眼檢查，是唯一可接受的驗證方式。
計算工具本身並不會主動回傳資料，因此可以在不將其上傳的情況下用於正式環境中的秘密。這個特性很重要：HMAC 值的可信度僅與產生它的環境相當，像 HMAC 產生器這樣的本機瀏覽器計算工具，能在計算標籤的同時將秘密保留在目前的分頁中。
如需更深入的說明，請參閱 Base58 解碼入門：以位元組為優先的工作流程。