在 Linux 上,SHA-512 雜湊是由 NIST FIPS 180-4 所定義、由 GNU coreutils 中的 `sha512sum` 輸出的 512 位元摘要(128 個小寫十六進位字元 / 64 位元組)。執行 `sha512sum file.iso` 時,會讀取檔案的原始位元組,將它們逐區塊送入 SHA-512 壓縮函式,更新八個 64 位元的工作變數,並將這些變數串接成單一十六進位字串。由於每一位元都會在排程中級聯傳遞,即使只修改一個位元組——多餘的尾端換行、UTF-8 位元組順序標記,或是經過正規化的重音字元——都會產生完全不同的摘要。這種雪崩效應正是 SHA-512 能用於下載檢查、軟體版本驗證,以及隨 Linux ISO 映像一同發佈的校驗碼清單的原因。以瀏覽器為基礎的 Sha512 雜湊產生器在本地端對 UTF-8 文字或您選擇的檔案位元組執行完全相同的演算法,絕不上傳任何一項,因此即使是在沒有終端機、或無法安裝工具程式的工作站上,仍能產生與重新執行的 `sha512sum` 位元組完全相容的摘要。

how to calculate sha512 hash in linux
how to calculate sha512 hash in linux

SHA-512 演算法會產生什麼,以及 `sha512sum` 會回傳什麼

SHA-512 屬於 NIST 發佈的 SHA-2 家族。它會將輸入訊息填充至長度為 1024 位元的倍數,將填充後的位元組切分為多個 1024 位元區塊,並透過壓縮函式處理每個區塊,改變八個 64 位元工作變數的值。處理完每個區塊後,這八個變數會依序串接,以 512 位元摘要的形式輸出。由於該演算法使用的是 64 位元字,而非 SHA-256 所使用的 32 位元字,因此同一份輸入在兩種演算法下所產生的雜湊值不會相符。

Linux 發行版會將 `sha512sum` 作為 GNU coreutils 的一部分一同出貨,因此在 Ubuntu、Debian、Fedora、Arch、Alpine 以及大多數容器映像中,無需額外安裝即可取得該執行檔。預設情況下,該指令會讀取檔案的原始位元組,並輸出一行包含 128 個小寫十六進位字元、兩個空格、模式指示符(二進位為星號、文字為空格)以及檔名的內容。空輸入是有效的,會產生以 `cf83e135` 開頭的標準摘要,如 NIST FIPS 180-4 所記載;空結果並非錯誤或格式上的意外。128 字元的數量正是 64 位元組乘以每個位元組兩個十六進位數字的直接結果,因此同一演算法始終會輸出相同數量的字元。

該摘要是確定性的,且極為敏感。即使可見文字看起來相同,新增句點、將換行從 LF 換成 CRLF、對 Unicode 進行正規化,或在開頭加上 UTF-8 位元組順序標記,都會產生完全不同的值。請將 `sha512sum` 視為位元組完全精確的校驗碼,而非語意相似性的測試;在與任何參考值進行比對之前,請先重現發佈者所指定的確切位元組。

從 Linux 命令列計算 SHA-512 雜湊

在 Linux 上,終端機是計算 SHA-512 雜湊最易於重現的位置,因為同一份 coreutils 套件會在每個相容的發行版上產生相同的位元組。每當可下載的產物、設定檔或密碼影子項目需要雜湊時,請依下列有序步驟進行:

  1. 開啟終端機並切換至存放產物的目錄,例如 `cd ~/Downloads`,使輸出的檔名能與您記錄的路徑一致。
  2. 執行 `sha512sum filename.iso`,以輸出包含 128 字元十六進位摘要、二進位或文字模式標記以及檔名的單行結果。
  3. 以 `sha512sum *.iso > checksums.txt` 批次處理多個產物。重新導向至清單檔,可將您打算發佈或簽署的摘要凍結保存。
  4. 重新下載或重新傳輸檔案,然後執行 `sha512sum -c checksums.txt`。`-c`(check)旗標會重新雜湊清單中的每個檔案,只有當重新計算的摘要與儲存的值逐字相符時,才會輸出 `filename: OK`。
  5. 對二進位內容使用 `-b` 旗標(`sha512sum -b firmware.bin`),若文字檔必須維持文字模式則使用 `-t` 旗標;二進位標記 `*` 與文字標記 ` ` 是唯一可見的差異。
  6. 若想在不寫入檔案的情況下雜湊短訊息,可將其透過管道傳送:`echo -n "message" | sha512sum`。`-n` 旗標會抑制 `echo` 預設會新增的尾端換行,因為這單一位元組就足以改變摘要。
  7. 當下游通訊協定需要 Base64 表示時,將輸出轉為帶填補的 Base64,例如 `sha512sum file.bin | awk '{print $1}' | xxd -r -p | base64`。SHA-512 摘要的帶填補 Base64 形式恰好為 88 個字元,即使只有一個大小寫錯誤的字母或少一個 `=` 填補字元,都會在無聲無息中導致比對失敗,因此在傳輸前務必再次核對。

若您的發行版缺少 `sha512sum`,或您偏好以單一指令轉換為 Base64,`openssl dgst -sha512 -binary file.bin | base64` 可在一行內產生相同結果。在您信任任一工具之前,其輸出的摘要必須與瀏覽器版 Sha512 雜湊產生器所產生的摘要相符,因此請在本地驗證該頁面時保持終端機視窗開啟。

如何透過瀏覽器計算 SHA-512 雜湊

終端機指令並非隨時可用——借來的工作站、上鎖的資訊亭、無 shell 存取權限的 CI 執行器,或單純的 UI 偏好,都可能將您推向以瀏覽器為基礎的路徑。Sha512 雜湊產生器會在頁面內完整執行 NIST 所定義的相同運算,因此訊息或檔案都不會離開您的瀏覽器。完整步驟如下:

  1. 對 UTF-8 字串選擇「文字」分頁,對本地產物選擇「檔案」分頁,並提供完全一致的來源——包括刻意保留的空白、尾端空格,以及可能在不知情狀況下被複製過來的隱藏換行。
  2. 在依賴摘要之前,請先讀取所回報的位元組數;若大小不符預期,往往是編碼飄移已悄悄發生的第一個線索。
  3. 同時讀取產生的 128 字元小寫十六進位結果與帶填補的 Base64 形式;兩者編碼的是同一份輸入的同一 64 位元組,屬於可互換的表示方式,而非兩個獨立的雜湊值。
  4. 複製消費者所要求的表示形式——傳統校驗碼與 `sha512sum` 清單使用小寫十六進位,偏好 Base64 的通訊協定則使用帶填補的 Base64——並將其貼入驗證步驟。
  5. 只要該值將作為發行版本的把關條件,就請將瀏覽器摘要與重新執行的 `sha512sum` 結果交叉比對。逐字相符是在信任任一方之前,您所能執行的最強本地健全性檢查。

當摘要將流經同樣偏好 Base64 的系統時,請牢記相關的 Linux shell 習慣:Linux 上的 Base64 解碼指南記載了與該頁面輸出相同的填補、字母與換行慣例,使得 shell 工具與瀏覽器工具之間的往返操作變得可預期。

完整 SHA-512 與 SHA-512/256、SHA-512/224 的比較

數個 SHA-2 成員共用 SHA-512 壓縮函式,但在初始值、截斷方式與發佈的測試向量上有所不同。SHA-512/256 與 SHA-512/224 是由 NIST 所定義,目的是在重複使用較寬的 SHA-512 硬體路徑的同時,提供 256 位元與 224 位元的輸出。手動截斷完整 SHA-512 並不會產生上述任一截斷變體,因為兩者使用不同的初始向量(IV)與獨立的最終化步驟。下表摘要了當您必須擇一並始終使用時,真正重要的外部可見屬性。

演算法輸出位元數輸出十六進位字元數是否與完整 SHA-512 右半部相同?
SHA-25625664否——壓縮函式不同
SHA-38438496否——初始向量不同,輸出自 SHA-512 狀態截斷
SHA-512512128是——即完整的 512 位元輸出本身
SHA-512/25625664否——初始向量與截斷方式皆不同
SHA-512/22422456否——初始向量與截斷方式皆不同

若廠商或發佈系統交給您一個 64 字元的十六進位字串,卻標示為「SHA-512」,那就是標示錯誤,幾乎可以肯定是 SHA-512/256 或被悄悄截斷;只有完整 SHA-512 才會產生 128 個十六進位字元。請務必確認發佈摘要旁所標示的確切演算法名稱,而不是從字串長度推測。

將下載的摘要與信任的參考值進行比對

雜湊的可信度,完全取決於遞送預期值的管道是否可信。在 Linux 上以 `sha512sum file.iso` 或在瀏覽器工具中(針對文字輸入)計算檔案的摘要,將結果貼上或以指令碼寫在維護者所印出的值旁邊,並逐字比對兩個字串。Linux 工具會輸出小寫十六進位;OpenSSL 會輸出大寫十六進位;瀏覽器工具會輸出小寫十六進位——一旦出現大小寫不符,某個字母就已悄然不同,因此在人工比對前請先統一大小寫,並將指令碼鎖定為單一風格。Sha512 雜湊產生器提供八個黃金測試案例——空訊息、"abc"、FIPS 多區塊訊息、標點變化、UTF-8 文字,以及任意的二進位位元組——您可在信任該頁面處理真實產物之前,將其作為頁面本身的自我測試來執行。

在 CLI 工作流程中,請將預期摘要儲存於與檔案本身不同的媒介:以分離式 GPG 簽章簽署清單、從第二個權威來源鏡像摘要,或使用您發行版已簽署的套件中繼資料。512 位元摘要本身並不會驗證任何東西;它只是縮小意外碰撞的機率,而能控制發佈管道的攻擊者可以交給您任何他們想要的摘要。請將摘要視為對傳輸過程的檢查,而非來源出處的證明。

Where Raw SHA-512 Is the Wrong Tool

SHA-512 has no key, so it has no built-in notion of who computed the digest — which means it cannot prove the sender of a message. When the goal is to confirm that data came from a specific party, you need either an HMAC built on SHA-512 (which adds a shared secret to the compression function) or a public-key signature that wraps the digest with the signer's private key. Hashing alone is sufficient only when integrity is the question and the expected value already lives in a trusted location, such as a signed checksum file or an authenticated distribution channel.

Raw SHA-512 is also the wrong choice for password storage. The algorithm's speed is a feature for file integrity and a liability for credential databases, because extremely high offline guessing rates are achievable on commodity GPUs. Real password storage uses a per-user random salt and a dedicated, tunable-cost function such as Argon2id, scrypt, or bcrypt. The Linux shadow suite applies exactly this principle when `crypt()` is invoked with the `$6$` prefix, which selects the SHA-512-based scheme but adds a unique salt and many rounds — so even the well-named "SHA-512 password" on Linux is not the same operation as a single-pass raw SHA-512 hash. Reach for the appropriate construction whenever the protocol or product you are implementing names it specifically; do not substitute a longer raw digest in place of authentication, signatures, or a tuned KDF.

Related reading: How to Get the SHA-1 Hash of a Certificate File.