【问题标题】：How to predict the next GUID from a given GUID?如何从给定的 GUID 预测下一个 GUID？
【发布时间】：2010-10-23 10:41:46
【问题描述】：

我已经向我们的客户发送了 10000 封邮件，每封邮件都有一个格式的链接

http://example.com/LogIn?key={guid}

可惜我发的guid是随机的guid（Guid.NewGuid()生成的测试数据）所以客户都收到了无效的链接...

根据我从网络服务器收到的 404，我有一些我发送的 guid。我读过 Windows 中的 guid 生成器很弱，因此您可以从已有的 guid 预测下一个 guid。有谁知道怎么做？如果我能做到这一点，我可以使我发送的 guid 有效，这样链接就会再次起作用。

【问题讨论】：

为什么不检查发送的邮件并解析从那里发送的 GUID？你有一些邮件服务器档案吗？或者您可以启用该表单的任何 GUID。并不是有一大群坏人等着利用您的报价，他们知道发送的链接的详细信息并且您没有 GUID（直到您在 S.O 上发帖）。
有没有办法获取您发送的内容的副本并进行处理？如果您有自己的邮件服务器，它可能会保留一份副本。
见：stackoverflow.com/questions/643445/…
很遗憾，邮件没有被记录下来。每个 guid 都与一组只有特定客户才能查看和编辑的数据相关联。这是一个密码。
我认为最好简单地重做该过程，并发送带有有效链接的电子邮件，并向您的客户道歉。

标签： cryptography email guid cryptanalysis

【解决方案1】：

Windows 生成 GUID 的方式已多次更改，互联网上许多看似可靠的建议完全错误（也许只是过时，也许总是完全错误）。

上次我研究这个（几年前，可能是 XP SP2）时，我直接进入操作系统代码查看实际发生的情况，它正在生成一个带有 secure random number generator 的随机数。

如果您以默认方式生成 GUID，我怀疑您会很幸运地从另一个 GUID 中预测它们。

【讨论】：

你有这方面的资料吗？也就是说，我为什么要相信你的话，因为这篇文章也是“在互联网上”的。你能确定.NET 4.5 和 MS SQL server 使用这个 OS 功能吗？
@SilverlightFox 好吧，它告诉您我是如何得出结论的，即使用调试器进入 Windows - 没有什么能阻止您这样做。 .NET 的源代码也可用（或者无论如何都可以轻松反编译），因此您也可以查看它。我的观点主要是，关于这一点的大多数“明确确认”的陈述都需要精确限定它们适用于哪些版本。
我已经问过这个as a new question，如果您有兴趣发布有关该主题的规范答案，我想邀请您回答？如果没有也没问题。谢谢。
Windows 2000 及更高版本对 v4 guid 使用加密随机算法。（来源：msdn.microsoft.com/en-us/library/…）话虽如此，你应该永远使用 guid 进行加密，只需直接使用 RNGCryptoServiceProvider (.NET) 或类似的东西，这就是它的用途。即使您了解 .NET GUID 使用 CSPRNG，其他 guid 算法也不会，通过使用 GUID，您表明它们在任何地方都是安全的，而且绝对不是。

【解决方案2】：

首先您需要知道它们是否符合 RFC4122，并且您需要获取版本。

如果是UUIDv1，可以预测

UUIDv1 由：

时间戳（自公历纪元以来的 100 ns 间隔）
版本 (1) 蚕食
两个（或三个，lol）位用于 RFC4122 合规性（这会导致在 [89ab] 中出现半字节）
时钟 ID（随机位）
节点 ID（常量 6 字节掩码）

您只需要遍历可能的时间戳。请注意，那里有很多 100 纳秒的间隔！

一些软件正在生成 UUIDv1（Grafana 仪表板 ID、Airbnb 列表等），但一些软件依赖于随机 UUID、UUIDv4。

如果是 UUIDv4，你可能会窃取 PRNG 上下文

正如 Nikolay «denish» Denishchenko（卡巴斯基）不久前所展示的，如果对生成 UUID 的进程具有调试访问权限，则可以窃取当前的 RC4 上下文并在其他地方复制多达 500000 个 UUID。这已在 Microsoft Windows XP 上进行了演示（嗨，Will Dean），它使用有趣的 8*RC4 机制，并且每 500000 个 UUID 只播种实际熵。

在 Windows 10 上（不完全是 Windows 版本，而是 .NET 框架或 rpcrt4.dll 版本），它不再是 RC4，而是 AES，大概用于 CTR 模式。大概有相同的熵重用。

欲了解更多信息，请查看我在那里所做的工作https://uuid.pirate-server.com/blog/

【讨论】：

【解决方案3】：

有几种不同类型的向导。类型 1 使用主机 ID（通常是 MAC 地址）、序列号以及当前日期和时间。类型 4 是完全随机的。如果它是 1 类 UUID，您可能会找出一组相当有限的可能 UUID，但即便如此，您也无法生成单个 UUID 序列，因此您将无法确定特定用户的特定 UUID。

【讨论】：

Type 4 是随机的，但规范中没有说明这种随机性在密码学上是安全的 - 这取决于实现。

【解决方案4】：

即使您可以预测下一个 GUID 也是不可靠的，但如果您有可用资源，则很可能是完全不可能的。

您最好的选择是简单地将任何不匹配的 GUID 的手动重定向添加到通用页面，该页面要么解释出了什么问题，要么只是以编程方式确定它们应该在哪里结束并将它们发送到那里。

【讨论】：

【解决方案5】：

GUID 的一部分是当前日期/时间。如果您碰巧按顺序收到其中两个，那么您可以知道它们的创建速度有多快，因此可以很有信心地预测序列。

【讨论】：

仅当它们是 1 类 GUID 时。