在使用md5散列它之后使用java.util.UUID是一個不錯的選擇嗎？

Question

我看到以下代碼。

.
. // some code
.
String guid = NetworkUtil.md5(java.util.UUID.randomUUID().toString())
.
. // guid is being used 
.

這是一個很好的方法，使用MD5 散列 版本4 UUID嗎？

根據UUID規范，UUID本身在生成的UUID的唯一性方面非常好，並且碰撞的可能性非常小。 因此，上面這段代碼實際上並沒有通過使用MD5對其進行散列來降低唯一性的質量，MD5現在是一種過時的散列機制，容易發生沖突和攻擊。

Answer 1

讓我們從這開始：

根據UUID規范，UUID本身在生成的UUID的唯一性方面非常好，並且碰撞的可能性非常小。

實際上，它並沒有這么說。 它不能說，因為那沒有意義。

事實上，如果UUID規范說明了類型4 UUID的唯一性，那么它就會說它們只是隨機數的來源 。 這取決於平台和RNG和UUID實施的質量。 如果我們可以假設一個完美的¹個隨機數源，則任何兩個（單獨生成的）UUID相同的概率在2 ^122中開啟; 即非常非常小。 另一方面，如果您的隨機數源較差，則成對碰撞的概率會增加。

因此，上面這段代碼實際上並沒有通過使用MD5對其進行散列來降低唯一性的質量，MD5現在是一種過時的散列機制，容易發生沖突和攻擊。

是。 但是MD5並不是真正的問題。

正如@Doug Stevenson所說，哈希UUID並沒有減少碰撞的可能性。 甚至對於沒有已知弱點的散列算法也是如此。 無論算法是什么，散列UUID都有可能增加碰撞的概率² 。

基本上，散列單個UUID沒有意義。

但是，如果您需要比類型4 UUID具有更小碰撞概率的令牌，則可以將N類型4 UUID連接成單個字節數組，然后為該數組創建哈希。 如果你有一個（強）M位哈希算法，並且你的UUID生成器有一個完美的隨機數源，那么碰撞的幾率應該大約是2 ^{分鍾（M，122 * N）} 。

---

^{1 - 也就是說，一個隨機位源，其中某人（攻擊者）不可能用50％的正確概率預測序列中的下一位。}

^{2 - 如果有任何兩個具有相同散列的不同UUID，則會發生這種情況。 即使對於強哈希算法，這也是可能的......除非您將其定義為衡量強度的標准。}

Answer 2

你只能通過散列它來使一個可能唯一的值變得更糟。 它不會變得更好或“更獨特”。 因此，除了將它變成可以在需要md5-hashed字符串的情況下使用的統一格式之外，沒有什么可以通過這樣的散列獲得。