我已经在网上搜索了多个资源，但到目前为止，对于 Microsoft 的 GUID 生成机制是否足够安全以保证将其用作跨应用程序的唯一 ID 的问题，我无法找到明确的答案。
为了澄清，通过“足够安全”，我的意思是询问用于生成 GUID 的算法是否有任何已知的弱点或漏洞，可能会降低 GUID 的有效随机性即导致不可忽略的碰撞次数。如果不是，这是否意味着 GUID 完全不可猜测，如果是，是否有某种方法可以为 GUID 生成器函数播种以有效增加生成的 GUID 的随机性。
根据此处的 MSDN 指南 (http://msdn.microsoft.com/en-us/library/system.guid.aspx) 中指定的信息，是否有任何迹象表明可以依赖用于生成 GUID 的系统具有足够的随机性。
谢谢！
【问题讨论】：
标签： .net security cryptography guid
我不同意接受的答案。虽然违背 RFC 的建议通常是个坏主意，但在这种情况下，我能够找到 MSDN 文档，指出 Microsoft 确实采取了明显、有用的路线，并将加密安全的 RNG 绑定到 v4 GUID 的生成中：
根据https://msdn.microsoft.com/en-us/library/system.guid.newguid(v=vs.110).aspx，.NET 的 GUID 创建只是包装了 Windows 函数 CoCreateGuid 和 UuidCreate。根据http://download.microsoft.com/download/5/0/1/501ED102-E53F-4CE0-AA6B-B0F93629DDC6/Windows/%5BMS-WSO%5D.pdf 的说法，自 1999 年的 Windows 2000 以来，
"获取Windows内置的所有版本4 GUID的随机位 通过 Windows CryptGenRandom 加密 API 或等效的， 用于生成加密密钥的同一来源"
所以我想说你可以称它们为密码安全——至少在它们提供的 122 位熵的范围内。
【讨论】：
SystemNative_GetNonCryptographicallySecureRandomBytes。
没有。 Guid 的目标是唯一，但加密安全意味着它是不可预测的。这些目标有时（但并非总是）一致。
如果你想要加密安全，那么你应该使用类似RNGCryptoServiceProvider
另见：
以上两个链接的重点是微软的Guid是UUID的实现，UUID spec indicates that they should not be used as security tokens：
不要假设 UUID 很难猜；例如，它们不应该用作安全功能（仅拥有授予访问权限的标识符）。一个可预测的随机数来源会加剧这种情况。
【讨论】：