UuidCreate 是否使用 CSPRNG？答案

【问题标题】：Does UuidCreate use a CSPRNG?UuidCreate 是否使用 CSPRNG？
【发布时间】：2016-05-23 19:48:05
【问题描述】：

请注意，这不是我的应用程序，它是我正在为客户测试的应用程序。我通常在https://security.stackexchange.com/ 上问这样的问题，但是因为这与编程相关，所以我在这里问过。

当然，UUID 的RFC 4122 没有指定类型 4 UUID 必须由加密安全伪随机数生成器 (CSPRNG) 生成。它只是说

将所有其他位设置为随机（或伪随机）选择价值观。

尽管该算法的某些实现，例如 this one in Java，确实使用了 CSPRNG。

我试图深入研究 Microsoft 的实施是否有效。主要围绕 .NET 或 MSSQL Server 如何生成它们。

查看.NET source我们可以看到这段代码：

 Marshal.ThrowExceptionForHR(Win32Native.CoCreateGuid(out guid), new IntPtr(-1));
 return guid;

检查CoCreateGuid docco，它指出

CoCreateGuid 函数调用 RPC 函数 UuidCreate

我能找到的关于这个函数的只有here。我似乎已经走到了兔子洞的尽头。

现在，有人知道UuidCreate 是如何生成其 UUID 的吗？

我看过很多相关的帖子：

第一个说：

GUID 不保证随机性，而是保证围绕独特性。如果你想要随机性，使用 Random 生成一个字符串。

我同意这一点，但在我的情况下，对于随机的、不可预测的数字，你当然会使用 CSPRNG 而不是 Random（例如 RNGCryptoServiceProvider）。

而后一种说法（实际引自维基百科）：

WinAPI GUID 生成器的密码分析表明，由于 V4 GUID 的序列是伪随机的；充分了解内部状态，可以预测之前和之后的价值观

现在，在围栏的另一边 this post 来自 Will Dean 说

我上次研究这个（几年前，可能是 XP SP2）时，我直接进入操作系统代码，看看实际上是什么正在发生，它正在使用安全生成一个随机数随机数生成器。

当然，即使它当前使用的是 CSPRNG，这也将是特定于实现的，并且随时可能发生变化（例如，对 Windows 的任何更新）。不太可能，但理论上是可能的。

我的意思是，这没有规范的参考，以上是为了证明我已经完成了我的研究，以上帖子都没有参考任何权威。

原因是我试图决定是否需要更改使用 GUID 进行身份验证令牌的系统。从纯粹的设计角度来看，答案是肯定的是，但是从实际的角度来看，如果 Windows UuidCreate 函数确实使用 CSPRNG，那么系统不会立即面临风险.任何人都可以对此有所了解吗？

我正在寻找任何有可靠来源的答案来支持它。

【问题讨论】：

奇怪的问题。假设有人说“是”。您是否要根据互联网上的陌生人告诉您的信息来确定系统的安全性？致电微软。
不，我要求以某种方式提供一些证据。例如see my comment here.
获取 Windbg 并进入通话，看看它做了什么。然后在某个时间点至少有一个操作系统，您就会知道。指南仍然不适合您使用它们的目的，但您至少可以解决这个问题。
这里的主要问题是您盗用 GUID 用于不适合的目的。实现是一个细节，无论当前的实现是什么，它都可能随时被任意更改。

标签： c# c++ windows security random

【解决方案1】：

虽然我仍然只是互联网上的某个人，但我只是重复了在 64 位版本的 Windows 10 上运行的 32 位应用程序中踏入 UuidCreate 的练习。

这是整个过程中的一些堆栈：

> 0018f670 7419b886 bcryptPrimitives!SymCryptAesExpandKeyInternal+0x7f
> 0018f884 7419b803 bcryptPrimitives!SymCryptRngAesGenerateSmall+0x68
> 0018f89c 7419ac08 bcryptPrimitives!SymCryptRngAesGenerate+0x3b
> 0018f8fc 7419aaae bcryptPrimitives!AesRNGState_generate+0x132 
> 0018f92c 748346f1 bcryptPrimitives!ProcessPrng+0x4e 
> 0018f93c 748346a1 RPCRT4!GenerateRandomNumber+0x11
> 0018f950 00dd127a RPCRT4!UuidCreate+0x11

很明显，它使用基于 AES 的 RNG 来生成数字。但是，通过调用其他人的 GUID 生成函数生成的 GUID 仍然不适合用作不可猜测的身份验证令牌，因为这不是 GUID 生成函数的目的 - 您只是在利用副作用。

您的“不太可能，但理论上可能”。关于操作系统版本之间实现的变化，“UuidCreate”文档中的以下语句相当地给出了谎言：

如果您不需要此级别的安全性，您的应用程序可以使用 UuidCreateSequential 函数，该函数的行为与所有其他操作系统版本上的 UuidCreate 函数完全相同。

即以前更容易预测，现在更难预测了。

【讨论】：

感谢您解决这个问题。为了支持您提供一些文档，根据msdn.microsoft.com/en-us/library/…，自 1999 年的 Windows 2000 以来，“Windows 中内置的所有版本 4 GUID 的随机位都是通过 Windows CryptGenRandom 加密 API 或等效的，相同的来源是用于生成加密密钥”。所以我想说你可以称它们为密码安全——至少在它们提供的 122 位熵的范围内。
@JordanRieger 我真希望你能把它放在答案中。 “微软的文档说他们这样做”似乎是一个与“我使用调试器并查看过”同样好的（但更权威）的答案?
@Jaykul 我实际上已经写了不止一个关于这个主题的这样的答案，只是没有关于这个特定的问题。如果您检查 OP 链接的相关问题，您可以看到它们。由于问题是处理将 Microsoft GUID 视为加密随机的具体风险，并且答案是正确地发现该风险很低，所以当评论就足够时，不需要额外的答案。但在其他问题上，当顶部的回答暗示 GUID 不安全时，我提供了一个完整的答案作为对立面。