SHA-512 雜湊（hash）加鹽（salt）是將鹽值與訊息串接後，餵入 NIST FIPS 180-4 中所定義的 SHA-512 演算法，所產生的 128 字元十六進位摘要。鹽只是在雜湊之前混入訊息中的額外輸入位元組；它不會改變演算法、不會加密任何東西，也不會隱藏結果。鹽的作用在於讓輸出具有唯一性：兩位使用相同密碼的使用者，因為鹽不同，會產生完全不同的 512 位元摘要，進而能抵擋預先計算的彩虹表（rainbow table）。Sha512 Hash Generator 會計算你所提供位元組的標準完整 512 位元 SHA-2 摘要，並以 128 個小寫十六進位字元或標準填補的 Base64 回傳 64 個位元組。這個工具本身不會加上鹽，它是一個確定性的摘要計算器；但因為你可以精確控制要被雜湊的位元組，所以只要在產生摘要前，將鹽輸入或貼在訊息旁邊，就能輕鬆加上鹽。本文將逐步說明鹽實際的作用、如何正確地與訊息結合，以及在什麼情境下使用加鹽的 SHA-512 雜湊是（或不是）合適的作法。
「SHA-512 加鹽」真正的含義
密碼學中的「鹽」並非餐桌上的食鹽；而是在雜湊之前混入訊息中的每筆記錄隨機值。最簡單的形式中，加鹽的 SHA-512 雜湊就是 SHA-512(salt || message) 或 SHA-512(message || salt)，其中 || 表示位元組串接。鹽通常是一段隨機位元組字串——常見的做法是以十六進位或 Base64 編碼的 16 個位元組——而且每筆記錄或使用者都應該擁有唯一的鹽，並與產生的雜湊一同儲存，以便日後能重現或遷移這個機制。
鹽只有一個明確的目的：防止竊取了雜湊資料庫的攻擊者立刻辨識出哪些使用者使用了相同的密碼。若沒有鹽，每個選擇「Password123」的使用者都會產生相同的摘要，這讓攻擊者能將破解成本攤提到整個資料庫上。有了唯一的隨機鹽，每個摘要看起來都互不相關，因此每組密碼都必須被個別攻擊，而預先計算查表這條廉價的捷徑也就消失了。
鹽做不到的事情也值得明確說明。鹽不是加密、沒有金鑰，也不會讓弱密碼變強。它無法保護對抗已經知道鹽的攻擊者，因為一旦資料庫外洩，鹽也包含在外洩資料中。鹽只是迫使攻擊者必須逐一攻擊每個雜湊，並消除大量預先計算的捷徑。
何時鹽有用、何時沒有用
只有當攻擊者可能建立一張能一次對應大量輸入到大量輸出的查詢表時，鹽才是必要的。最典型的例子就是密碼儲存：每位使用者都會有自己的鹽，讓相同的密碼產生不同的雜湊。對於其他任務，鹼並沒有任何附加價值，適合的做法是完全不同的機制。
| 情境 | 需要鹽嗎？ | 正確的作法 |
|---|---|---|
| 驗證下載的檔案 | 否 | 與可信賴的已發布摘要比對 |
| 儲存使用者密碼 | 是，每位使用者唯一 | 使用 Argon2id、scrypt 或 bcrypt，並調整工作因子 |
| 驗證 API 請求 | 否，應改用金鑰 | 搭配共享密鑰的 HMAC-SHA-512 |
| 證明訊息是由誰簽署 | 否 | 數位簽章機制（RSA-PSS、Ed25519） |
| 內容定址識別碼 | 否 | 對正規化後的位元組直接進行 SHA-512 |
如果你的任務是驗證下載的檔案是否符合發布者釋出的內容，相關的保護機制是透過可信通道取得的已發布檢查碼，並不涉及鹽。如果你的任務是在共享密鑰的兩方之間驗證訊息，合適的基礎演算法是 HMAC-SHA-512，它將金鑰混入雜湊中，而非使用每筆記錄的隨機鹽。鹼是針對儲存的秘密所設計的每筆記錄防禦機制；它並非 SHA-512 的一般性強化手段。
使用 Sha512 Hash Generator 產生加鹽雜湊
由於這個工具會對你所提供的位元組原封不動地進行雜湊，產生加鹽的 SHA-512 雜湊就只需要準備輸入字串後按下產生按鈕。請依照下列步驟以確保輸出可以重現：
- 決定你的鹼組合模式：先鹽後訊息，或先訊息後鹽。請將這個約定記錄下來，以便日後能重現。
- 產生或挑選一個鹽值。以 32 個十六進位字元編碼的 16 個隨機位元組是合理的預設值；請將它另外記錄在預計儲存摘要的位置。
- 開啟 Sha512 Hash Generator，並將輸入模式保持為 UTF-8 文字。
- 依你決定的順序，將鹽與訊息貼上或輸入到文字方塊中。請將空白、換行字元以及位元組順序標記（byte-order mark）視為輸入的一部分，因為每一個位元組都會計入。
- 點擊產生按鈕，等待 128 字元的十六進位結果出現，然後複製它。
- 若接收端預期使用 Base64，請切換輸出格式並複製編碼後的結果。不論使用哪種格式，背後的 64 個位元組都完全相同。
- 將輸出與你手上的任何可信賴參考值逐字元比對，若接收端日後需要驗證，請將鹽與摘要一同儲存。
第四步中最關鍵的細節在於位元組的精確性。SHA-512 是確定性的，而且對輸入極為敏感。SHA-512("abc") 的已發布值為 ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f。多一個換行、結尾多一個空格，或 Unicode 正規化方式改變，都會產生完全不同的 128 字元字串。當你將鹽混入密碼時，請明確記錄串接規則，包括鹽是否需要從十六進位解碼回原始位元組，還是視為 ASCII 字面字元，以便日後能重現雜湊結果。
鹽的編碼方式以及文字與檔案的選擇
鹽值通常是隨機位元組，但文字輸入欄位只能接受字元。這個落差正是許多加鹽雜湊實作出錯的地方。這個工具會對你所輸入內容的 UTF-8 位元組表示進行雜湊，因此十六進位字串「a1b2c3」會被當作 6 個 ASCII 位元組進行雜湊，而不是 0xa1、0xb2、0xc3 這 3 個原始位元組。若你的通訊協定指定使用原始鹽位元組，請改以檔案形式貼上這些位元組，而非以文字形式貼上，或者另外將十六進位解碼回實際位元組後再與訊息串接。在從文字或檔案產生 SHA-512 雜湊的逐步說明中，對這項取捨有更詳細的說明。
另一個相關的陷阱是換行字元的正規化。許多文字編輯器與剪貼簿操作會在 Windows 上悄悄地將 LF 轉成 CRLF，或完全移除結尾的換行字元。若你需要位元組層級的精確重現性，請使用一個未經任何轉換就儲存的檔案來進行雜湊，或者從你已經計算過位元組數的來源貼入工具。這個工具會在 UTF-8 轉換後回報最終的位元組數，這是快速確認輸入過程中沒有新增或遺失內容的便捷檢查方式。
對於多位元組字元，UTF-8 編碼後的位元組數可能與字元數不同。「café」這個詞是 4 個字元，卻佔 5 個位元組，因為 é 在 UTF-8 中佔 2 個位元組。若你的鹼含有非 ASCII 字元，或密碼中含有帶有變音符號的字母，請使用文字模式進行雜湊，並在信任摘要前先確認顯示的位元組長度符合預期。
加鹽的 SHA-512 仍然不是密碼儲存函式
值得直接說清楚：SHA-512(salt || password) 並不是你應該用來儲存使用者密碼的方式。NIST FIPS 180-4 中的演算法設計目的是追求速度，這對於檔案完整性與簽章工作負載是優點，對密碼儲存卻是缺點。一張現代 GPU 每秒可以計算數十億次 SHA-512 雜湊，這代表攻擊者一旦竊取到加鹽 SHA-512 密碼雜湊資料庫，仍然能對每筆紀錄每秒嘗試數十億次猜測。
適合用來儲存密碼的工具是專門設計的密碼雜湊函式，這類函式刻意讓每次猜測變慢，並需要大量記憶體。Argon2id 是目前的第一選擇，scrypt 與 bcrypt 則是廣泛使用的替代方案。這些函式會接收鹽、密碼以及工作因子參數，並在一個自包含的字串中同時輸出鹽、成本設定以及最終雜湊。使用它們時，你不需要自行串接鹼。
原始的加鹼 SHA-512 仍有合法的用途——例如，從已知明文與已發布的隨機值衍生出每筆記錄的識別碼，或重現另一個系統指定的確切演算法——但在保護儲存的密碼時，請改用慢速 KDF。其代價是每次登入多耗費數毫秒，這對使用者毫無感覺，卻會對嘗試暴力破解資料庫的攻擊者造成毀滅性打擊。
將加鹽雜湊與可信賴參考值比對
一旦取得 128 字元的十六進位結果，驗證步驟就是能抓出幾乎所有真實世界中錯誤的關鍵。請逐字元比對，不要只比對前幾個與最後幾個。即使只有一個十六進位數字調換位置，雜湊看起來表面上很相似，實際上卻是完全不同的值。若接收端預期使用 Base64，請使用 Base64 表示法進行驗證，而不是自行將十六進位轉成 Base64，否則可能造成填補錯誤。
請確認所儲存或發布的摘要確實是完整的 SHA-512。SHA-512/256 與 SHA-512/224 是使用不同初始化值的不同演算法，分別會產生 64 字元與 56 字元的十六進位輸出；它們並非從完整 SHA-512 結果截斷而來。若你要重現的通訊協定指定的是這些變體，請使用確切的變體，而不是把完整 SHA-512 摘要貼到需要截斷版本的欄位，然後認為「差不多」就可以了。
最後，請將可信賴的參考值與你正在檢查的檔案存放在不同的通道上。與下載檔案放在同一頁、由同一台伺服器提供的 SHA-512 雜湊值，幾乎無法對抗已被入侵的主機所提供的完整性保護。參考值必須透過可信的管道取得——例如經簽署的發行版本、第二個網站、透明度記錄——否則比對結果只能確認檔案本身內部一致，而無法確認它與發布者實際釋出的內容一致。
如需更深入的說明，請參考 HMAC Generator 速查表：雜湊、編碼、輸出規則。