HMAC-SHA-256 會根據共用密鑰與訊息產生完整的 32-byte 驗證標記，而 HMAC 產生器可讓您計算該標記，無須加密或隱藏訊息。對初學者而言，核心任務是讓四項內容相符：雜湊演算法、完全相同的金鑰位元組、完全相同的訊息位元組，以及接收系統所要求的輸出格式。HMAC 產生器支援 HMAC-SHA-256、HMAC-SHA-384 和 HMAC-SHA-512。您可以分別將金鑰和訊息表示為 UTF-8 文字或完全相同的十六進位位元組，然後以小寫十六進位和標準填補 Base64 取得完整標記。這兩種輸出會編碼相同的標記，並非兩個不同的 HMAC 結果。此頁面使用瀏覽器的 Web Cryptography API，將所選的金鑰位元組匯入為不可匯出的 HMAC 金鑰，且不會將輸入內容傳送至網站伺服器。金鑰材料會保留在目前的分頁中。因此，此工具適合用於檢查已記載的測試向量、準備通訊協定請求，或重現另一個系統應計算的值。請先確認適用通訊協定的演算法、位元組編碼、欄位順序、空白字元慣例和標記規則，再開始操作。請試用 HMAC 產生器，直接在瀏覽器中完成這些工作。
初次使用者的 HMAC 基礎知識
HMAC 會將密碼學雜湊與共用密鑰金鑰結合。傳送者會根據完全相同的訊息位元組計算標記，而持有相同密鑰和訊息位元組的驗證者也能計算出相同的標記。標記不一致可能表示訊息遭到修改；標記相符則可驗證某一方確實知道共用金鑰。任何得知該金鑰的人都能建立看似有效的標記，因此 HMAC 仰賴妥善保護金鑰。
HMAC 不會隱藏訊息。接收者仍可讀取明文，看到訊息的觀察者也能讀取。加密是另一項獨立操作。HMAC 架構本身定義於 NIST FIPS 198-1。
選擇雜湊與欄位編碼
請使用適用通訊協定指定的雜湊，不要依個人偏好選擇。所選雜湊會決定完整標記的長度：
| 演算法 | 完整標記大小 | 選擇規則 |
|---|---|---|
| SHA-256 | 32 bytes，或 256 bits | 當通訊協定指定 HMAC-SHA-256 時使用。 |
| SHA-384 | 48 bytes，或 384 bits | 當通訊協定指定 HMAC-SHA-384 時使用。 |
| SHA-512 | 64 bytes，或 512 bits | 當通訊協定指定 HMAC-SHA-512 時使用。 |
此頁面一律顯示完整標記。請確認通訊協定是否預期取得完整的該項結果。如果其規格定義了截斷、演算法前置字串或其他傳輸編碼，請記錄確切規則，但在執行該步驟前，保持原始完整標記不變。
輸入編碼是與演算法選擇分開決定的。金鑰和訊息可以各自獨立使用 UTF-8 或十六進位。
| 輸入模式 | 提供給 HMAC 的位元組 | 初學者檢查項目 | 適用情況 |
|---|---|---|---|
| UTF-8 | 在該欄位中輸入文字的 UTF-8 編碼。 | 空格、換行符號和多位元組字元都會影響結果。 | |
| 十六進位 | 每一組十六進位數字所代表的確切位元組。 | 請使用完整的成對位元組，不要加上前置字串或分隔符號。 |
這些模式控制的是如何提供輸入位元組，並非選擇 HMAC 演算法。十六進位特別適合用於已發布的測試向量和二進位欄位，因為每個位元組都很明確。
產生完整 HMAC 標記
- 確認演算法。 依照適用通訊協定的指定，選擇 SHA-256、SHA-384 或 SHA-512，並在套用任何另外定義的轉換前，確認預期取得的是完整 HMAC 標記。
- 輸入密鑰金鑰。 為金鑰欄位選擇 UTF-8 或十六進位。輸入通訊協定要求的確切密文或完整位元組序列，不要加上標籤、前置字串或格式。
- 另外輸入訊息。 為訊息選擇其本身的 UTF-8 或十六進位模式。保留指定的欄位順序、大小寫、空格、標點符號及任何必要的結尾換行符號。
- 產生標記。 執行產生器。瀏覽器會將所選金鑰位元組匯入為不可匯出的 Web Crypto HMAC 金鑰，而簽章操作會傳回完整標記。此頁面會將相同的位元組呈現為小寫十六進位和標準填補 Base64。
- 複製所需的表示形式。 當接收系統預期使用十六進位時，請使用小寫十六進位。當文件指定的格式為標準填補 Base64 時，請使用該格式。不要將外觀相似的編碼視為可互換。
- 依規格完成處理。 只有在通訊協定明確要求時，才對標記進行轉換或截斷。請將訊息和標記存放或傳輸至指定的欄位，不要假設產生器已替您包裝。
輸入界限： 每個已解碼的金鑰或訊息欄位最多只能有 1,000,000 bytes。介面會拒絕空白金鑰和空白訊息，以避免意外產生結果，即使某些低階標準可能定義了零長度資料的行為。非同步工作會帶有識別權杖，因此舊輸入產生的結果不會覆寫較新的輸入狀態。
控制每個輸入位元組
HMAC 處理的是位元組，而非文字的可見含義。對於每個設為 UTF-8 的欄位，此工具都會將輸入文字編碼為 UTF-8。帶重音的字母、CJK 字元和 emoji 可能佔用多個位元組，而空格或結尾換行符號也會各自增加位元組。除非通訊協定要求，否則不要刪除空白或替換換行符號。產生標記前，請確認每個欄位應使用 UTF-8 編碼 或十六進位位元組。
十六進位模式會保留每個位元組，包括值為零的位元組。它只接受偶數個十六進位數字，並拒絕前置字串、空格、冒號和奇數半位元組。這種嚴格解析可避免格式字元在無聲無息間改變通訊協定值。簡潔的十六進位字串與看似相關的文字字串不一定代表相同輸入，因此請為每個欄位使用指定的模式。
已發布的向量和二進位內容通常以十六進位表示最清楚，因為位元組邊界一目了然。對一般文字而言，UTF-8 較易閱讀，但最終仍由編碼後的位元組序列決定結果。
以所需形式傳遞標記
小寫十六進位和標準填補 Base64 是相同標記位元組的兩種呈現方式。解碼任一種表示形式都會產生相同的完整 HMAC 值。輸出選擇很重要，因為接收通訊協定會定義標記的表示和傳輸方式。
此產生器不會輸出 Base64url、不會在開頭加上演算法識別字串，也不會將訊息和標記包裝在一起。通訊協定可能要求其中一種格式，但也可能要求標準化請求字串或二進位封裝。如果標準化請求字串就是待驗證資料，請先組合其確切位元組，再產生標記。如果最終格式要將訊息與已產生的標記一起包裝，請另外依規格建立該包裝。切勿憑肉眼縮短完整標記，也不要移除字元直到它看似符合大小限制。
追查結果不一致的問題
當兩個系統產生不同標記時，請依照相同順序比較相同的決策：
- 確認兩個系統都依指定使用 SHA-256、SHA-384 或 SHA-512。
- 比較確切的金鑰位元組，包括任何必要的密碼派生。
- 確認金鑰和訊息都採用預期的 UTF-8 或十六進位解讀方式。
- 檢查空白、換行符號、結尾換行符號、字元編碼和欄位順序。
- 確認已簽署的內容是原始訊息、標準化請求字串或已定義的封裝。
- 比較以所需表示形式呈現的完整標記，包括任何明確的截斷或 Base64url 規則。
進行受控檢查時，請使用已發布的 RFC 4231 測試向量，不要使用即興建立的範例。此產生器的正確性檢查已鎖定至八個完整的一致性標記：SHA-256 有四個，SHA-512 有四個。這些案例涵蓋短金鑰、重複的二進位金鑰和資料、小於摘要值的金鑰，以及跨越雜湊區塊邊界的資料。逐位元組重現向量，比不斷切換演算法直到某個結果看似合理更有用。
將金鑰視為安全材料
正確的 HMAC 計算並不會使弱金鑰變得安全。請使用獨立產生、具備高熵且適合該通訊協定的金鑰材料，透過受保護的通道分發，依用途分離金鑰，並在遭到洩漏後予以輪替。人類使用的密碼通常熵值太低，不適合作為原始 HMAC 金鑰。當應用程式允許使用以密碼為基礎的金鑰時，請使用該應用程式要求的確切密碼金鑰派生函式和參數，不要自行臆測。
如果通訊協定預期使用產生的隨機密文，請使用適合該通訊協定、獨立產生且具備高熵的金鑰材料。請確認可列印文字是否為要求的金鑰格式；有些系統反而預期原始金鑰位元組。不要僅因 HMAC 產生器在目前的瀏覽器分頁中處理資料，就把正式環境中的密鑰貼入不受信任的裝置。
驗證應在伺服器端執行，並使用固定時間函式比較標記。結果相符只證明共用金鑰和位元組一致，並不代表訊息具備機密性。任何同時取得訊息和密鑰的人都能讀取明文並偽造新的有效標記。