SHA-1 檔案摘要是一組 160 位元的指紋,代表構成該檔案的精確位元組,會以正好 40 個小寫十六進位字元,或 28 個標準 Base64 字元(含任何填補字元)的形式印出。這不是加密:沒有任何資料會被解密,之後也無法從摘要還原任何內容,只要位元組相同,在任何合規的實作上都會產生相同的摘要。要計算檔案的 SHA-1 雜湊值,你要把工具指向檔案的原始位元組,而不是它的檔名或修改時間,只要輸入的位元組相同,每次都會得到相同的 20 個摘要位元組。以瀏覽器為基礎的 Sha1 Hash Generator 會在本機端讀取檔案,在位元組緩衝區上執行 FIPS 180-4 SHA-1 運算,並同時以小寫 Hex 與含填補的 Base64 顯示結果,而不會將檔案傳送到伺服器。160 位元的輸出在有限的工作流程中可以偵測偶發的傳輸損壞,但 SHA-1 在安全性方面已被破解出碰撞,因此這個摘要絕對不能視為作者身分證明,也不能用於簽章、憑證決策、密碼儲存,或用於敵對情境下的檔案核准。
什麼時候 SHA-1 檔案摘要是合適的工具
許多舊版的下載頁面、檔案總錄,以及長期維護的軟體鏡像站,仍然會在檔案旁邊公布 SHA-1 校驗碼。當你需要與這類系統互動時,唯一正確可用來比對的演算法,就是發布者當初所記錄的那一個。這就是計算檔案 SHA-1 雜湊值具有正當性的實際情境:你想確認下載到的位元組與發布者最初發布的位元組一致,而發布者只留下了 SHA-1。
SHA-1 在這個相容性範圍內仍然有用,因為它會產生一個穩定且固定長度的識別碼,任何符合標準的實作都會給出相同結果,而且這個演算法體積小到可以在本機的瀏覽器分頁中執行。根據 NIST Secure Hash Standard (FIPS 180-4),訊息摘要會將輸入分割成 512 位元的區塊,每個區塊經過八十個回合更新五個 32 位元的狀態字,最終輸出正好 160 位元。這個結果短到可以目視檢查、貼進問題追蹤系統,或存放在純文字檔中,這正是舊版發布者選擇它的原因。
超出這個範圍,SHA-1 不應該是你在新設計中選用的演算法。請把檔案摘要視為僅用於偵測偶發損壞的校驗碼,而非安全性基元。當舊版下載頁面、檔案總錄或老舊整合系統公布了 SHA-1 校驗碼,而你需要比對精確的位元組時,本頁是有用的;但當你正在設計該系統的下一代版本時,它就是不適合的工具。
如何計算檔案的 SHA-1 雜湊值
- 在瀏覽器中開啟 Sha1 Hash Generator,並把輸入控制項切換到檔案模式而非文字模式。
- 從本機磁碟選擇你想要雜湊的檔案。瀏覽器會透過本機 API 讀取檔案,位元組不會離開這個分頁;上限是 100 MB,因為輸入必須在執行摘要之前放入單一個位元組緩衝區中。
- 點擊計算按鈕。網頁會對所讀取的原始位元組執行標準的 SHA-1 壓縮函式;檔名、檔案的修改時間,以及瀏覽器的 MIME 標籤,都不會納入摘要之中。
- 讀取頁面所顯示的 40 字元 Hex 字串,以及 28 字元 Base64 字串。它們是同一組 20 個摘要位元組的兩種編碼方式,所以如果 Hex 與 Base64 互相轉換後與頁面結果不一致,代表你複製貼上時出了錯。
- 複製符合舊版系統所預期格式的那個表示法,然後關閉檔案選擇器,不要重新儲存或重新編碼來源檔案。
如果你要雜湊的檔案是文字而非二進位資料,同一個工具的文字模式會先把可見字串編碼為 UTF-8 再進行雜湊。這個差別對帶有變音符號的字母、表情符號,以及非拉丁文腳本來說很重要,因為單一字元可能佔用好幾個位元組,所以兩個視覺上相似的輸入可能會雜湊出兩個不同的摘要。空輸入也是一個有效的訊息,會產生那個眾所周知的 SHA-1 值 da39a3ee5e6b4b0d3255bfef95601890afd80709,但你仍然必須點擊按鈕:空欄位和「沒有結果」並不相同。
Hex 與 Base64:該複製哪一種表示法
SHA-1 會產生 20 個位元組。這個工具會以舊版系統實際使用的兩種編碼方式呈現這些位元組,你應該複製消費者端所預期的那一種,而不是另外用其他工具自行轉換。格式不符,是手動比對在第一次就失敗最常見的原因之一。
| 格式 | 長度 | 字元集 | 通常出現的位置 |
|---|---|---|---|
| 小寫 Hex | 40 字元 | 0-9, a-f | sha1sum 命令列輸出、*.sha1 sidecar 檔案、大部分下載頁面 |
| 標準含填補 Base64 | 28 字元(含填補) | A-Z, a-z, 0-9, +, /, = | 舊版 API、manifest 欄位、內嵌的設定 blob |
Hex 是檔案校驗碼最常見的格式,所以當發布者在下載連結旁放上一個值時,它幾乎一定是 Hex。Base64 較為精簡,出現在需要高密度的協定承載中。不要把 Hex 字串餵進預期接收 Base64 的系統,反之亦然:兩者的字元外觀不同,且這兩種字串不可互換,任何多出或缺少的首尾字元都會在下游悄悄讓比對失效。
將計算出的摘要與已公布的校驗碼比對
SHA-1 檔案摘要只有在與來自你信任管道的參考值進行比對時才有意義。RFC 6194 記錄了適用於 SHA-1 的安全性考量,並提醒實作者該演算法不適用於碰撞抵抗,因此比對步驟必須根據這個限制來設計,而不是憑空抱持期望。
比對本身很簡單:依序將所複製摘要的每一個字元,與你所收到的值進行比對,不要修剪空白、不要正規化大小寫,也不要重新編碼來源檔案。若相符,即確認兩個位元組序列逐位元相同,這在受控的鏡像工作流程中已足以偵測偶發的傳輸損壞。若不相符,代表位元組不同、編碼步驟改動了某些內容,或參考值本身就是錯的;你不應該回頭修改來源檔案來「讓它相符」。
三個習慣可以讓比對保持誠實:
- 即使大小寫看起來與你用過的其他網站不同,也一律以發布者所用的相同管道與大小寫來複製摘要。
- 盡可能從第二個可信任的位置取得參考值,如此發布者的網頁就不是預期值唯一的出處。
- 把摘要連同檔案一起記錄在你自己的筆記中,讓下一個人有東西可以比對,而無須再從原始來源重新推導。
什麼時候不該選用 SHA-1
SHA-1 已被破解出碰撞。實際攻擊已經證明,在符合現實條件下,不同的內容可以被刻意打造出共用同一個 SHA-1 摘要,這使得該演算法不再適用於任何對抗性情境。下表整理了 SHA-1 在哪些地方作為舊版相容性檢查是可接受的、在哪些地方無害但沒有意義,以及在哪些地方是積極有害的。
| 任務 | SHA-1 是否可接受? | 建議的演算法或做法 |
|---|---|---|
| 比對舊版下載頁面公布的校驗碼 | 可以,但僅限於相容用途 | 請發布者將參考值遷移到 SHA-256 |
| 在私人鏡像中偵測偶發的損壞 | 可以,但需理解其適用範圍 | 新管線請使用 SHA-256 或 SHA-512 |
| 對文件或可執行檔進行數位簽章 | 不行 | 請搭配真正的簽章機制,使用 SHA-256 或更強的演算法 |
| 在信任決策中比對憑證指紋 | 不行,不能作為安全性輸入 | 請使用 SHA-256 指紋;SHA-1 只能視為舊版提示 |
| 密碼儲存 | 不行 | 請使用有加鹽、刻意耗時的 KDF:Argon2id、scrypt 或 bcrypt |
| 核准由不可信任方上傳的檔案 | 不行 | 請在已驗證的通道上使用 SHA-256 或更強的演算法 |
有一個特別值得提出的情境是密碼雜湊。密碼的純 SHA-1 摘要並不是密碼雜湊。通用型雜湊演算法刻意做得很快,所以攻擊者每秒可以對洩漏出來的資料庫測試大量的猜測值。密碼儲存應該使用的正確基元,是諸如 Argon2id、scrypt 或 bcrypt 這類有加鹽、刻意耗時的密碼雜湊機制,並在擁有該憑證的帳號系統內部套用。Sha1 Hash Generator 既不會加鹽也不會衍生金鑰,所以即使在本機端用它來「儲存密碼」也是不安全的。
限制、邊界情況，以及超過 100 MB 時的處理方式
該頁面所使用的瀏覽器 API 必須在 SHA-1 演算執行之前，將整個選取的輸入載入單一位元組緩衝區，因此本工具的檔案上限為 100 MB。此上限並非串流實作，因此數 GB 的磁碟映像、長影片檔案，或非常龐大的封存檔都會超出限制。若要處理更大的檔案，請在 Linux 上執行值得信賴的本機作業系統工具，例如 sha1sum；在 Windows 上執行 certutil -hashfile；在 macOS 上執行 shasum，並確認該指令實際呼叫的演算法以及實際讀取的位元組。
其他幾個邊界情況即使看起來沒有改變，也會使摘要產生變化：
- 行尾換行。以 Unix 換行符結尾的檔案，與沒有結尾換行符的相同檔案相差一個位元組，SHA-1 會為兩者分別回傳不同的值。Windows 的 CRLF 換行與相同內容的 LF 換行也會產生不同的摘要。
- 空白字元。尾端空格、定位字元 (Tab)，以及最後的空白行都會參與雜湊運算；外觀相似的輸入仍可能正確地產生不同的摘要。
- 編碼。文字模式的雜湊是針對 UTF-8 位元組進行，而非字元。兩個經過 toLowerCase 呼叫後看起來相同的字串，若其中一個使用組合附加符號 (combining accent)、另一個使用預組合形式 (precomposed)，其雜湊結果仍可能不同。
- 空輸入仍是有效的訊息，SHA-1 會回傳空輸入的摘要 da39a3ee5e6b4b0d3255bfef95601890afd80709。在此情況下並沒有可略過點選按鈕的捷徑。
若您能掌控接收端系統，針對檔案 checksum 問題最持久的解決方案，是將儲存的參考摘要遷移至 SHA-256 或 SHA-512，並透過經驗證的管道發布新的 checksum。在完成遷移之前，請在合適的最小工具中計算檔案的 SHA-1 雜湊值，複製舊有接收端所預期的 Hex 或 Base64 表示法，並在不修剪或重新編碼原始來源的前提下，逐字元與可信的參考值進行比對。
若您正在權衡各種選項，如何取得檔案的 SHA-512 雜湊值對此有詳細說明。
若您正在權衡各種選項，如何解讀 Vigenère 密碼：對齊金鑰對應位置對此有詳細說明。