雜湊計算

雜湊是什麼，跟加密、編碼差在哪

雜湊（hash）函數把「任意長度的輸入」轉成「固定長度的輸出」，且具有三個關鍵性質：

• 單向性：從 hash 值無法回推原文（與加密最大差異）
• 決定性：相同輸入永遠得到相同 hash
• 雪崩效應：輸入改一個字元，hash 完全不同

這些性質讓 hash 非常適合「驗證資料是否相同 / 沒被篡改」，但「不能還原原文」的場景。 SHA-2（包含 SHA-256、SHA-384、SHA-512）由美國 NSA 設計，NIST 於 2001 年標準化；SHA-3（基於 Keccak 演算法）於 2015 年成為新標準，設計概念與 SHA-2 完全不同，為未來潛在攻擊預備。

Hash vs 加密 vs 編碼

三個常被混為一談的概念：

• Hash（雜湊）：單向、無法還原。例：SHA-256 用於驗證檔案完整性
• 加密：雙向、有對應的解密過程、需 key。例：AES 加密訊息，收件人用 key 解開
• 編碼：雙向、純格式轉換、無 key。例：Base64 用於把二進位塞進文字環境

分不清楚的代價很具體：把密碼「雜湊起來」以為就是加密好了，或是把 Base64 當成一種保護。 前者少了 salt 與慢演算法照樣會被撞開，後者任何人都能一行還原。

各演算法用途

四種本頁一次全算好，不用先選；對方公布哪一種就比哪一種，沒有人指定時看 SHA-256。

• SHA-1（40 字元）：已不安全，避免新系統使用。Git 還在用，舊系統相容性。
• SHA-256（64 字元）：最常見、TLS、區塊鏈、JWT HS256、檔案完整性的事實標準。
• SHA-384（96 字元）：較少用，TLS 1.3 部分套件採用。
• SHA-512（128 字元）：64-bit 系統上比 SHA-256 快，適合大檔案 checksum。

字元數就是分辨依據：手上那串 checksum 有幾個字元，就知道對方用的是哪一種。把它貼進「貼上官方 checksum 比對」欄位，工具會照長度認出演算法、直接告訴你相符或不相符；32 個字元的是 MD5，瀏覽器算不了。

核對下載回來的檔案有沒有被動過

1. 先到官方下載頁把公布的 checksum 抄下來，注意它標的是哪一種演算法。這一步一定要從官方網站抄，從轉載站抄就失去意義了。
2. 按上面的「選擇檔案」挑那個下載回來的檔案。檔案只會被讀進這個分頁計算，不會上傳。
3. 把官方那串貼進「貼上官方 checksum 比對」欄位。工具照長度認出是哪一種演算法，跟算出來的那一格比，不分大小寫、不看空白；相符時那一格會框成綠色並標「相符」。
4. 交給工具比，不要用眼睛掃。雪崩效應保證只要檔案差一個位元組整串就完全不同，但人眼很容易看漏中間某一碼。
5. 對不上就重新從官方來源下載一次再算，先不要安裝或解壓縮。

選了檔案之後，上方文字框就先被擱在一邊；想回去算文字，按檔名旁邊的叉，或直接改文字框的內容。

確認兩段文字是不是一模一樣

1. 把第一段文字貼進文字框，複製其中一種演算法的結果。
2. 清空文字框，貼進第二段，再看同一種演算法的結果。兩串相同就是完全一致。
3. 結果不同卻看不出差在哪，多半是看不見的東西：行尾的空白、Windows 與 Unix 的換行差異、檔案開頭的 BOM，或是全形與半形的標點。
4. 比對整個設定檔或整份文件時，改用「選擇檔案」比貼文字可靠， 因為貼上的過程本身就可能被編輯器改掉縮排或換行。

HMAC-SHA256：驗 webhook 簽章，以及台灣金流的檢查碼

HMAC 是帶密鑰的雜湊（RFC 2104）：同一段內容換一把密鑰就是另一個值，所以收到的一方用自己手上的密鑰重算一次，就能確認內容是對方送的、途中沒被改過。工具最下方的 HMAC-SHA256 區塊填上密鑰，就會對上面的文字框（或選的檔案）算，同時給 hex 與 Base64 兩種寫法；把收到的簽章貼進「要比對的簽章」，會直接告訴你相符與否。

• LINE 的 x-line-signature：Messaging API 用 channel secret 當密鑰，對 webhook 請求的 body 原文算 HMAC-SHA256，再轉成 Base64，所以要看 Base64 那格。LINE 文件特別提醒 body 要用收到的原字串：先解析成 JSON 再轉回字串，多一個空白就對不上。
• 綠界的 CheckMacValue：不是 HMAC。官方的算法是把參數照英文字母排序、用& 串起來，前面加 HashKey、後面加 HashIV，整串 URL encode 後轉小寫，做 SHA256 再轉大寫。要用這頁對算法，把轉小寫之後的那串貼進上面的文字框，SHA-256 那格轉大寫就是 CheckMacValue；拿綠界文件上的範例字串貼進來，會得到跟文件一樣的 6C51C9E6…（只差大小寫）。最常算錯的是 URL encode：結果要符合綠界的「.NET 編碼」對照表，PHP 的 urlencode() 會把 !、*、(、) 編成 %21這類寫法，綠界要的是原字元，得換回來。
• 藍新的 TradeSha：也不是 HMAC。官方手冊的做法是在 AES 加密後的 TradeInfo 字串前面加 HashKey=…&、後面加 &HashIV=…，做 SHA256 再轉大寫。AES 那一步本頁不做；手上已經有 TradeInfo 的話，把整串組好貼進文字框，SHA-256 那格轉大寫就是 TradeSha。

HashKey、HashIV 與 channel secret 都是正式的憑證。本頁只在你的分頁裡用、不會上傳，但能用測試環境的金鑰就別貼正式的。伺服器端比對簽章時，記得用常數時間的比較函式（例如 Node.js 的 crypto.timingSafeEqual），不要直接用 ==。

把算出來的值帶走

• 大小寫：本頁輸出小寫十六進位，中間沒有空白也沒有分隔符號。有些網站公布的是大寫， 兩者是同一個值；貼進比對欄位時大小寫與空白都會自動忽略。綠界 CheckMacValue、藍新 TradeSha 要的是大寫，送出前記得轉。
• 貼進文件或工單：值很長，貼進 Markdown 或聊天室時用程式碼區塊包起來，避免被自動換行或自動格式化切斷。
• 存成檔案：要跟著檔案一起發布，習慣的做法是另存一個同名的 checksum 檔，裡面放「值 空格 檔名」，並且在發布頁面上也寫一份。

瀏覽器算得出什麼，各系統的指令是什麼

為什麼沒有 MD5？

瀏覽器原生 crypto.subtle API 不支援 MD5，因為 MD5 已被證實能在實際時間內找到碰撞， 不適合任何安全用途。本工具用瀏覽器原生 API 做純前端計算，不引入第三方 lib，所以僅支援 SHA 系列。 若只為了檔案完整性檢查（非安全用途），用 SHA-256 即可。

同一個值，各系統怎麼自己算

• macOS：shasum -a 256 檔名，或openssl dgst -sha256 檔名。
• Linux：sha256sum 檔名，另有 sha1sum、sha512sum。
• Windows：PowerShell 的 Get-FileHash -Algorithm SHA256 檔名。
• Node.js：crypto.createHash 支援的演算法比瀏覽器多，MD5 與 SHA-3 都在裡面。
• Git：物件識別碼用的是 SHA-1，所以你在紀錄裡看到的那串 40 字元不是檔案內容的 SHA-256。

同一個檔案在這些工具裡算出來的值應該完全一樣。不一樣就代表兩邊算的不是同一個東西： 檢查是不是算到了壓縮檔外層、下載到一半的暫存檔，或是文字檔被編輯器改過換行。

瀏覽器這邊還有一個前提：crypto.subtle 只在安全的連線 （HTTPS 或本機）下提供，所以本頁在一般網路環境都能用，但把這份程式碼搬到用 HTTP 開的頁面上就會拿不到 API。

可以丟什麼進來，以及做不到的事

因為運算走瀏覽器原生的 crypto.subtle.digest()，這是作業系統層級的 C 實作，你的輸入從頭到尾沒離開這個分頁。 大檔案 checksum 也一樣，讀檔與計算都在本機，算 1GB 的 ISO 也不會產生半個 byte 的上傳流量。

• 檔案是整個讀進分頁的記憶體再算的。幾百 MB 以內都很順，真的很大的映像檔建議改用上面那幾行系統內建指令，比較不會讓分頁吃掉記憶體。
• 雜湊只證明「內容沒變」，不證明「內容可信」。官方頁面本身被改掉的話， 上面公布的值也會一起被改，這種情況要靠數位簽章而不是 checksum。
• SHA-1 留在這裡是為了對照舊系統的值，新的簽章或驗證用途不要選它。
• HMAC 的密鑰跟文字一樣只在這個分頁裡用，不會上傳也不會寫進網址；但密鑰本來就不該到處貼，能用測試環境的就用測試環境的。
• 不要把密碼、金鑰或個資丟進來「順便雜湊一下」當成保護。雜湊值本身不是機密的替身， 密碼的正確作法在常見問題第一題。