请注意，这不是我的应用程序，它是一个我为客户端testing的应用程序。 我通常在https://security.stackexchange.com/上提问这样的问题，但是这是我在这里询问的更多编程相关的问题。
当然，UUID的RFC 4122并没有规定types4的UUID必须由密码安全的伪随机数发生器（CSPRNG）生成。 它只是说
将所有其他位设置为随机（或伪随机）select的值。
尽pipe该algorithm的一些实现（例如Java中的这种algorithm）确实使用了CSPRNG。
我试图深入了解微软的实施是否成功。 主要围绕.NET或MSSQL Server如何生成它们。
检查.NET源代码，我们可以看到这个代码：
Marshal.ThrowExceptionForHR(Win32Native.CoCreateGuid(out guid), new IntPtr(-1)); return guid; 检查CoCreateGuid docco，它说
CoCreateGuid函数调用RPC函数UuidCreate
所有我能find关于这个function在这里 。 我似乎已经到了兔子洞的尽头。
现在，有没有人有关于如何UuidCreate生成其UUID的任何信息？
我见过很多相关的post：
其中第一个说：
GUID不保证随机性，它保证了唯一性。 如果你想随机，使用随机生成一个string。
我同意，除了在我的情况下，随机，不可预测的数字，你当然会使用CSPRNG而不是Random （例如RNGCryptoServiceProvider ）。
而后者的状态（实际上是从维基百科引用的）：
WinAPI GUID生成器的密码分析表明，由于V4 GUID的序列是伪随机的; 在充分了解内部状态的情况下，可以预测之前和之后的值
威尔·迪恩说，现在，围栏的另一边
上一次（几年前，可能是XP SP2）研究了这个问题之后，我直接进入操作系统代码，看看实际发生了什么，并且用安全的随机数生成器生成一个随机数。
当然，即使目前正在使用CSPRNG，这也将是特定于实现的，并随时可能发生变化（例如Windows的任何更新）。 不太可能，但理论上可行。
我的观点是没有任何规范的参考，上面是为了certificate我已经完成了我的研究，上面的这些post都没有引用任何权威的东西。
原因是我试图决定是否需要更改使用GUID作为authentication令牌的系统。 从纯粹的deviseangular度来看，答案是肯定的，然而从实际的angular度来看，如果Windows UuidCreate函数事实上使用了CSPRNG，那么系统没有直接的风险。 任何人都可以解释这一点吗？
我正在寻找一个有信誉的来源备份它的答案。
尽管我还只是互联网上的一些人，但我只是重复了在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函数在所有其他版本的操作系统上的行为完全相同。
即过去更加可预测，现在不太可预测。