SHA-512 雜湊值是 NIST FIPS 180-4 定義的固定長度 512 位元摘要，以恰好 128 個小寫十六進位字元（64 個位元組）或標準補位 Base64 的形式寫出。要產生一個，你要把輸入的確切位元組序列——UTF-8 文字或檔案的原始位元組——餵給演算法，然後複製產生出來的摘要。這項運算是決定性的：相同的位元組永遠會產生相同的 128 字元字串，而只要改動一個位元，輸出就會完全不同。現代瀏覽器可以透過 Web Crypto 或 JavaScript 實作，在本地端完整執行 SHA-512 函式，這代表你要雜湊的訊息永遠不必離開你的裝置。像Sha512 雜湊產生器這類工具，套用的是未經修改的 FIPS 180-4 程序，並回傳同一組 64 位元組的標準小寫 Hex 與補位 Base64 兩種形式，讓你能把數值貼到接收端所預期的任何地方。由於這個摘要是逐位元精確的，實務上的工作大多在於保持原始位元組不變、選對表示方式，以及把每一個字元都與你信任的參考值比對。
「建立 SHA-512 雜湊值」實際上是什麼意思
SHA-512 是 SHA-2 家族中的其中一個特定成員。它透過一連串 1024 位元的訊息區塊、每個區塊 80 個字的排程，以及八個 64 位元工作變數（其最終值會被串接起來），把任何輸入（在實作的實際上限內）壓縮成 64 個位元組。這套數值程序完整標準化於NIST FIPS 180-4之中，所以任兩個正確的實作，對同一個輸入永遠會得到相同的結果。
當人們說「建立一個 SHA-512 雜湊值」時，通常是指以下三項具體工作之一：
- 為總和檢查碼、清單檔或 API 酬載，產生一個字串的 128 字元 Hex 摘要。
- 為一個檔案產生 512 位元摘要，以驗證它與發布者公布的摘要相符。
- 在協定明確要求 SHA-512 時，為高保證完整性工作流程產生一個不含金鑰的指紋。
在這三種情況下，你要拿來比對的都是同一組 64 位元組序列。選擇 Hex 還是 Base64，純粹取決於接收端系統預期的是哪一種表示方式，因為兩者編碼的是完全相同的位元組。
有兩個事實很容易被忽略，但值得牢記。第一，SHA-512 是逐位元精確的，所以任何你包含進去的空白——尾端的空格、文字結尾的換行、UTF-8 位元組順序記號——都會成為輸入的一部分並改變輸出。第二，這個演算法沒有金鑰、沒有祕密。一個 SHA-512 摘要本身只能證明輸入與輸入相符；它不能證明是誰產生了它，也不能證明它來自某個特定來源。
三個步驟產生 SHA-512 雜湊值
要取得經過驗證的摘要，最快的方式是使用一個本地端的瀏覽器工具，它會針對你確切的位元組執行完整的 FIPS 180-4 程序，然後讓你複製標準輸出結果。不論你的輸入是打出來的字串還是下載的檔案，都適用同一套工作流程。
- 選擇輸入模式，並提供確切的來源內容。選擇文字模式並輸入字串——包括任何刻意加入的空白——或切換到檔案模式並選取本地端檔案。文字路徑會先把你的字串轉成 UTF-8 再進行雜湊運算，並回報產生出來的位元組數；而檔案路徑則直接對原始位元組進行雜湊，不會解讀檔名、字元集或 MIME 類型。這兩種模式都共用 100 MB 的輸入上限，因為平台的摘要運算會一次接收一整個緩衝區，所以處理數 GB 大小的檔案時，請改用可靠的串流式命令列實作。這樣的區分，能避免把二進位檔案誤當成文字解碼、然後對修改過的表示方式而非原始檔案進行雜湊這種常見錯誤。
- 產生完整的 SHA-512 值並複製它。這個工具會回傳恰好 128 個小寫十六進位字元，以及同一組 64 位元組的標準補位 Base64 形式。大多數軟體流程請使用 Hex 字串，當接收端要求緊湊表示方式時則使用 Base64 字串。兩者編碼的是完全相同的摘要。如果你需要改從終端機執行同一項運算，Linux SHA-512 工作流程透過 OpenSSL 使用的是同一套 FIPS 180-4 程序。
- 把每一個字元都與可信的參考值比對。從一個經過驗證的來源讀取預期數值——NIST 測試向量、發布者已簽署的發行說明，或 RFC 範例——並逐字元檢查。務必確認接收端要求的是完整的 SHA-512，而不是 SHA-384、SHA-512/256、HMAC-SHA-512，或數位簽章，因為即使看得見的輸入完全相同，這些都不會與原始的 512 位元摘要相符。
SHA-512 與較短的 SHA-2 變體
完整的 SHA-512 並不是 SHA-2 家族中唯一使用 512 位元區塊的成員，混淆這些變體是摘要不相符最常見的原因之一。下表列出了與 SHA-512 共用 1024 位元區塊大小的四種演算法，以及驗證者應該預期的十六進位字元輸出長度。
| 演算法 | 輸出位元數 | 十六進位字元數 | 規範出處 |
|---|---|---|---|
| SHA-512 | 512 | 128 | NIST FIPS 180-4 |
| SHA-384 | 384 | 96 | NIST FIPS 180-4 |
| SHA-512/256 | 256 | 64 | NIST FIPS 180-4 |
| SHA-512/224 | 224 | 56 | NIST FIPS 180-4 |
SHA-512/256 與 SHA-512/224 有時會被誤認為是完整 SHA-512 的截斷版本，但它們實際上使用不同的初始狀態值與一個獨立的最終化步驟。手動截斷完整的 SHA-512 輸出，並不會重現 NIST 所公布的 SHA-512/256 數值。當某個協定、清單檔或 API 指定使用這兩種較短變體之一時，你必須執行那個確切的演算法——例如專用的SHA-256 雜湊產生器或 HMAC 建構方式——而不是從一個 128 字元的字串上直接剪掉幾個位元組。
十六進位字元數也說明了為什麼快速的「看起來對」比對是有風險的。SHA-512/256 摘要是 64 個十六進位字元，恰好是完整 SHA-512 長度的一半，所以一個對某個演算法而言形狀正確的結果，對另一個演算法而言形狀就是錯的。在把一個摘要視為有效之前，務必確認演算法名稱和預期長度兩者都正確。
為什麼原始的 SHA-512 不是密碼雜湊
這個問題背後的關鍵詞經常把「SHA-512」與「密碼雜湊」配在一起，但這兩個概念其實方向相反。原始的 SHA-512 是為了速度、完整性與短固定長度識別碼而設計的。密碼儲存需要的則恰恰相反：一個緩慢、加鹽、工作量係數可調的函式，讓離線攻擊者無法用一般硬體暴力破解。
有三項特性很重要：
- 沒有鹽值。剛好選了相同密碼的兩個使用者，會產生相同的 SHA-512 摘要。攻擊者利用這種相等性，配合彩虹表以及對整個外洩資料庫進行平行猜測。
- 沒有拉伸運算。現代 GPU 每秒能計算數十億次 SHA-512 摘要。一個密碼驗證機制應該讓每一次猜測都刻意變得昂貴。
- 沒有帳戶脈絡。這個摘要只是密碼本身的函式，沒有混入使用者名稱、版本標籤或胡椒值。
標準的密碼儲存做法，是使用一個專用的、記憶體密集或高疊代次數的函式，搭配每個使用者各自獨立的鹽值。目前廣泛推薦的演算法是 Argon2id（目前的預設選擇）、scrypt 與 bcrypt，這些演算法都需要明確的工作參數與鹽值，並回傳一個自成一體的編碼字串。如果你的應用程式只支援原始的 SHA-512，正確的做法是升級雜湊方案，而不是拿 SHA-512 當替代品用。SHA-512 本身在驗證訊息的身分上也毫無作用。HMAC-SHA-512 加入了一個共享祕密以進行驗證，而數位簽章則提供另一種來源驗證模型；兩者都需要一組原始摘要所沒有的金鑰或金鑰對。
將你的摘要與可信參考值比對驗證
產生摘要只完成了一半工作。另一半是要確認你產生出的數值與接收端所預期的相符，這代表你要把摘要逐字元地與一個透過你信任的路徑取得的參考值比對。
幾項具體檢查能讓驗證更容易：
- 測試向量。空字串有一個廣為人知、以 cf83e135 開頭的 SHA-512 摘要，三位元組的 ASCII 字串 abc 也有已公布的 FIPS 測試向量。如果你的工具對這些確切的輸入產生出這些確切的字串，代表它的實作與標準一致。
- UTF-8 位元組數。在文字模式下，工具會回報它實際雜湊了多少個 UTF-8 位元組。非 ASCII 字元通常會產生多位元組序列，所以一個含有一個表情符號的 7 字元字串，雜湊時可能是 10 或 11 個位元組。如果預期的位元組數與回報的不符，通常代表存在隱藏的正規化處理、一個殘留的 BOM，或行尾字元的轉換。
- 僅限完整的 SHA-512。一個正確的結果永遠是 128 個小寫十六進位字元。如果接收端預期的是 SHA-384、SHA-512/256、HMAC-SHA-512 或簽章，即使看得見的輸入完全相同，它的數值也不會與原始的 SHA-512 摘要相符，這種不相符是應該換用別的演算法的訊號，而不是去截斷輸出結果。
- 經過驗證的參考來源。更長的摘要並不能彌補一個不可信的參考來源。預期數值仍然必須透過你能夠驗證的管道取得——一份已簽署的發行版本、廠商具有效憑證鏈的 HTTPS 網站，或內部的成品儲存庫。對錯誤的預期數值做雜湊，只能確認演算法有在運作，並不能確認該成品是真實可信的。
這些驗證標準本身記載於RFC 6234之中，該文件重新陳述了供一般網際網路用途使用的 SHA-256 家族演算法，並提供參考程式碼，任何正確的實作都應該能重現其輸出結果。
相關閱讀：使用零寬度位元的文字隱寫術替代方案。