我不是第一次遇到這個問題，經常使用 UUID 的專案會對性能產生影響，有時會在幾秒鐘內生成 UUID。
我知道為什么會這樣。這個問題不是關于如何解決它，那里有很多資訊。我更好奇它是否真的如此普遍以至于它應該成為默認值......
Java 在生成時默認使用 SecureRandom UUID.randomUUID()，但是大多數人使用 UUID 作為他們放入資料庫中的不同內容的 ID，例如用戶、交易、訂單 ID 或任何其他物體 ID……但這些并不敏感在安全性方面（或者我錯了嗎？），如果您是一名黑客并且您知道如何猜測這些 ID，那么它不會給您任何優勢。如果有人生成一個 uuid 并對其執行 MD5 并將其存盤為新帳戶的默認密碼，這很重要......非常罕見的情況，但很明顯它是敏感資料，真正的隨機性在這里很重要。
我在這里的論點是 99% 的 UUID.randomUUID() 使用實際上并不關心真正的隨機性，并且使用安全隨機對他們來說不是可取的行為。我在這里想念什么嗎？我不是黑客，我遇到過一些看似無害的情況，但最終在安全性方面卻很重要。
所以我的問題是：假設人們不對敏感資料（例如私鑰/密碼生成）使用生成的 UUID，那么為物體 ID 提供安全隨機性真的很重要嗎？這在 UUID 生成中真正重要的情況是什么？
uj5u.com熱心網友回復：
隨機 (v4) UUID 必須提供大約 128 位的隨機性。為了正確地做到這一點，需要使用具有至少 128 位熵的 PRNG，以便輸出最終不會相互關聯或具有阻止它們獨立的模式。出于同樣的原因，該 PRNG 也不能暴露其內部狀態，這意味著它幾乎肯定需要是一個 CSPRNG。
此外，UUID 需要是通用唯一的：這就是為什么它們被稱為通用唯一識別符號。如果它們基于弱 PRNG，例如具有 32 位種子的 PRNG，尤其是在種子基于時間等簡單事物的情況下，不同的系統可能會生成相同的 UUID。如果您同時部署了大量系統，并且所有系統都在同一時間開始了基于時間的弱 PRNG，則情況尤其如此。
此外，還有一些速度非常快的 CSPRNG。ChaCha20 是 Linux 內核中使用的 PRNG，每個內核可以輸出超過 3 GB/s。Rust 使用 ChaCha12 作為其默認 PRNG，它在密碼學上也是安全的，甚至更快，并且可以配置為使用每個執行緒選項。我不知道 Java 的默認選項是什么，但它本質上沒有理由需要很慢，而且由于有許多快速、安全的選項，所以當你不需要時沒有理由使用弱選項。
最后，使用安全默認值是有意義的。如果我們讓人們在快速但非獨特和慢但獨特之間做出選擇，許多人會選擇錯誤并最終導致損壞或安全問題，因為它有點快。我們不提供這些選項，因為正如我所提到的，在幾乎不需要它們并且有很多缺點的情況下提供可能導致損壞或安全漏洞的選項是不謹慎的。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/409808.html
標籤：