使用 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 ¹²²；即非常非常小。另一方面，如果随机数来源较差，成对碰撞的概率就会增加。

那么，上面的这段代码实际上是不是通过使用 MD5 进行散列来降低唯一性的质量，MD5 现在是一种过时的散列机制，并且容易发生冲突和攻击。

是的。但 MD5 并不是真正的问题。

正如 @Doug Stevenson 所说，对 UUID 进行哈希处理并不会减少冲突的可能性。即使对于没有已知弱点的哈希算法也是如此。无论采用哪种算法，对 UUID 进行哈希处理都有可能增加冲突的概率²。

所以基本上，对单个 UUID 进行哈希处理是没有意义的。

但是，如果您需要比类型 4 UUID 具有更小的冲突概率的令牌，则可以将 N 个类型 4 UUID 连接到单个字节数组中，然后为该数组创建哈希。如果您有一个（强大的）M 位哈希算法，以及 UUID 生成器的完美随机数源，那么冲突的几率应该大约为 2^{分钟一分之一(M, 122 * N)}。

^{1 - 也就是说，随机位的来源，其中某人（攻击者）不可能以 50% 正确概率以外的任何方式预测序列中的下一位。}

^{2 - 如果任意两个不同的 UUID 具有相同的哈希值，就会发生这种情况。即使对于强大的散列算法也是可能的......除非您将其定义为衡量强度的标准。}