Blake2 vs md5 用於校驗和/文件完整性
我正在研究需要計算校驗和/文件完整性的東西。我聽說不再推薦使用 MD5。我應該改用 Blake2 嗎？我應該將 Blake2 的特定變體用於校驗和嗎？
Blake2s?Blake2sp?
是的，您應該選擇 BLAKE2 而不是 MD5。 任何BLAKE2 變體（BLAKE2s、BLAKE2b、BLAKE2sp、BLAKE2bp）都是對 MD5 的改進，即使您只是將它們用於 MD5 等 128 位摘要大小，但通常最好使用至少 256 位摘要。BLAKE2b 是一個很好的預設值；BLAKE2s 在 64 位系統上速度較慢，但對 32 位系統更友好；BLAKE2sp 和 BLAKE2bp 針對具有大型向量單元或多核的系統進行了優化，以並行化散列長消息。
所以去撕掉MD5，換上BLAKE2，你幾乎肯定會過得更好。
你撕掉了MD5？好的！但是我們也應該首先談談你想用它做什麼，因為雖然 BLAKE2 並不比 MD5差，但 MD5 和 BLAKE2 或任何具有相同形狀的東西（一個固定的雜湊函式）都不能做無論他們在做什麼方面做得多麼出色。
所以，當你說“校驗和”和“文件完整性”時，你想做什麼？以下是一些可能性：
- 您正在嘗試使用非常簡單的分佈來檢測隨機錯誤，例如獨立錯誤或突發錯誤。
在這種情況下，雖然 BLAKE2 並不比 MD5差，但使用**設計為校驗和（如 CRC）而不是設計為隨機函式（如 BLAKE2 和 MD5 ）可能會更好：
- 一個 CRC 多項式，其因子為 $ x + 1 $ 保證檢測所有奇校驗錯誤。
- 一個 $ n $ 非零位 CRC $ x $ 術語保證檢測 $ n $ 位突發錯誤。
- 通過明智地選擇生成多項式可以保證檢測到各種其他錯誤；有關更多詳細資訊，請參閱標準 Koopman–Chakravarty 參考資料（預印本、免費付費）。當不涉及對手時，這是相關的。
- 您正在與與您分享秘密的人進行對話 $ k $ ，並且您想防止其他人偽造消息。
在這種情況下，您實際上需要一個消息驗證碼或 MAC，它具有以下屬性：任何不知道密鑰的人都無法找到任何消息的 MAC，除非他們已經禮貌地要求您提供給他們。
BLAKE2 有一個內置的 MAC：你可以指定一個密鑰，它會神奇地變成一個 MAC。還有其他替代方案，例如 HMAC-SHA256，甚至是 HMAC-MD5（據我們所知，它仍然安全到遠低於 $ 2^{64} $ 消息，但您應該考慮切換，以便您的程式碼中根本沒有 MD5）。
- 您正在發布您希望世界上任何人都能夠驗證但沒有人能夠偽造的聲明。
在這種情況下，您實際上需要簽名，它們與 MAC 類似，只是有用於簽名（私鑰）和驗證（公鑰）的單獨密鑰。原則上 BLAKE2 可以在簽名方案中使用，但實際上我還沒有看到任何好的簽名方案，任何實用的簽名方案都會為任何散列函式提供預先確定的選擇，例如 Ed25519 使用 SHA-512 而 Ed448 使用 SHAKE256。
當然，任何想要驗證消息的人都需要先驗地知道公共驗證密鑰：如果他們在與簽名消息相同的頻道上獲得它，那麼攻擊者可能已經替換了整個東西——但至少接收者將擁有下一次的公鑰，因此攻擊者必須在接收者每天嘗試獲取公鑰和/或簽名消息時替換整個內容。
- 您正在分發中發布文件清單，例如軟體包儲存庫，並且清單發佈在不同的渠道上- 已知是不可偽造的，例如因為您通過 SSH 或 HTTPS 從一個好的伺服器獲得它 - 從軟體包本身——例如，因為您通過 HTTP 從粗略的 CDN 下載它們。
在這種情況下，BLAKE2 是一個不錯的選擇！如果您使用 MD5，您可能會遇到麻煩。但是您也應該確保在傳輸清單的通道和傳輸文件的通道之間實際上存在質的安全差異；如果對手可以同時修改兩者，則雜湊將一事無成。
- 您在內容定址儲存方案中使用雜湊作為鍵，例如Tahoe-LAFS。
在這種情況下，BLAKE2 是一個不錯的選擇！如果你使用MD5，你肯定會遇到麻煩。