在使用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字符串的情况下使用的统一格式之外，没有什么可以通过这样的散列获得。