c# - UuidCreate 是否使用 CSPRNG？

Question

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

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

Set all the other bits to randomly (or pseudo-randomly) chosen values.

虽然，该算法的一些实现，例如 this one in Java ，请使用 CSPRNG。

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

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

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

查看CoCreateGuid docco，它说

The CoCreateGuid function calls the RPC function UuidCreate

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

现在，有没有人知道 UuidCreate 如何生成其 UUID 的任何信息？

我看过很多相关的帖子:

• How Random is System.Guid.NewGuid()? (Take two)
• Is using a GUID a valid way to generate a random string of characters and numbers?
• How securely unguessable are GUIDs?
• how are GUIDs generated in SQL Server?

第一个说:

A GUID doesn't make guarantees about randomness, it makes guarantees around uniqueness. If you want randomness, use Random to generate a string.

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

而后一种说法(实际引自维基百科):

Cryptanalysis of the WinAPI GUID generator shows that, since the sequence of V4 GUIDs is pseudo-random; given full knowledge of the internal state, it is possible to predict previous and subsequent values

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

The last time I looked into this (a few years ago, probably XP SP2), I stepped right down into the OS code to see what was actually happening, and it was generating a random number with the secure random number generator.

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

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

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

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

Answer 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 仍然不适合用作不可猜测的身份验证 token ，因为这不是 GUID 生成函数的目的 - 您只是在利用副作用。

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

If you do not need this level of security, your application can use the UuidCreateSequential function, which behaves exactly as the UuidCreate function does on all other versions of the operating system.

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