傑森·A·多南菲爾德, VPN WireGuard 的作者 廣為人知 幾天前一個新的實現 從隨機數生成器 RDRAND 更新，它負責Linux內核中的/dev/random和/dev/urandom設備的操作。
XNUMX 月底，Jason 被列入了隨機控制器的維護者名單，現在已經公佈了他的第一個返工成果。
公告中提到，新的實施值得注意的是 切換到使用 BLAKE2s 哈希函數而不是 SHA1 用於熵混合操作。
BLAKE2s 本身俱有內部基於
ChaCha 排列，RNG 已經用於擴展，所以
新奇，獨創或驚人的CPU應該沒有問題
行為，因為它基於已經在使用的東西。
此外，值得注意的是，變化 還提高了偽隨機數生成器的安全性 通過擺脫麻煩的 SHA1 算法並避免覆蓋 RNG 初始化向量。 由於 BLAKE2s 算法在性能上領先於 SHA1，因此它的使用也對偽隨機數生成器的性能產生了積極影響（在採用 Intel i7-11850H 處理器的系統上進行的測試顯示速度提高了 131%）。
另一個突出的優點是將熵混合物轉移到 BLAKE2 是所用算法的統一：在ChaCha密碼中使用BLAKE2，已經用於提取隨機序列。
BLAKE2s 通常更快，當然更安全， 它真的很破碎。 此外， RNG 中的當前構建不使用完整的 SHA1 函數，因為 指定並允許用 RDRAND 輸出覆蓋 IV，因此 未記錄，即使 RDRAND 未配置為“受信任”，這 代表可能的惡意 IV 選項。
它的長度短意味著 回饋到攪拌機時只保留半個秘密 只給我們 2 ^ 80 位的前向保密。 換言之，不僅 哈希函數的選擇已經過時，但它的使用也不是很好.
此外，對 getrandom 調用中使用的加密安全 CRNG 偽隨機數生成器進行了增強。
還提到了 改進減少到限制對 RDRAND 生成器的調用 提取熵的速度很慢，這 可以將性能提高 3,7 倍。 Jason 演示了對 RDRAND 的調用 只有在CRNG還沒有完全初始化的情況下才有意義，但是如果CRNG初始化完成了，它的值不會影響生成流的質量，這種情況下可以不用調用蘭德。
該承諾旨在解決這兩個問題，同時保持 一般結構和語義盡可能接近原文。
具體來說：a) 不要用 RDRAND 覆蓋 IV 哈希， 我們放入記錄在案的 BLAKE2 “鹽”和“個人”字段，它們是 專為此類用途而創建。
b) 由於此函數將完整哈希的結果返回給 熵收集器，我們只返回一半的長度 哈希，就像以前一樣。 這增加了 2 ^ 80 a的施工進度秘密 2^128 舒服多了。
c) 而不是僅僅使用原始的“sha1_transform”函數， 相反，我們使用完整且適當的 BLAKE2s 函數，並完成。
更改計劃包含在內核 5.17 中 並且已經被開發人員 Ted Ts'o（隨機驅動程序的第二個維護者）、Greg Kroah-Hartman（負責保持 Linux 內核穩定）和 Jean-Philippe Aumasson（BLAKE2 算法 /3 的作者）審查過。
最後，如果您有興趣能夠了解更多，可以在 以下鏈接。