为什么.NET是；管理的；如果启用了Windows FIPS符合性策略，则不允许使用加密类？

我一直在努力使我们的.NET应用程序符合FIPS标准，并发现

Managed

加密类（如

aessmanaged

）不符合FIPS标准。我已经阅读了一些关于哪些类是兼容的其他文章和问题，例如和。CryptoServiceProvider类似乎符合FIPS，但托管类则不符合

我只是想知道是否有人能解释一下

CryptoServiceProvider

类和

Managed

类之间的区别？如果有人能解释为什么

CryptoServiceProvider

类符合FIPS，而托管类则不符合FIPS，那么我可以向老板解释为什么我必须重写我们的加密方法。它们在本质上是不同的吗？或者MS只是没有对管理类进行NIST认证？如果

Managed

类只是包装

CryptoServiceProvider

类，那么为什么

Managed

类不能自动符合FIPS？如果我编写一个类来将符合FIPS的类包装成我自己更容易使用的类，那么我的软件是否不再符合FIPS

谢谢。

“符合FIPS标准”是一个错误的术语-您指的是经过FIPS认证的产品。区别在于，如果算法需要与参考实现和第三方实现兼容，那么它需要与描述该算法的相应FIP兼容。但认证是另一回事

CryptoServiceProvider类调用CryptoAPI（非托管Windows API）来执行实际的加密操作，并且一些CryptoAPI模块经过FIPS认证（出于业务目的）。显然，没有足够的理由来认证.NET托管类-如果您需要认证的模块，请使用CryptoAPI模块。认证需要花费大量的时间、精力和金钱

另外，我猜可能有技术原因阻止托管模块进行认证，但这只是一个猜测。NET（IL和虚拟机）的性质可能与为认证过程定义的某些要求相矛盾，即它们无法被认证

---

至于你自己的包装类——有几家公司自己提供人员培训和认证。他们还提供咨询服务。我希望这类服务的人员在这里作出回应，但如果需要，您也可以联系他们。

谢谢，您的解释很有帮助。我研究了CryptoServiceProvider类的实现，并意识到实现将与托管类完全相同。直到那时我才真正明白你所说的，CryptoAPI类只是包装了Windows API代码，并且已经通过了认证。但是托管类完全是用托管的.NET代码从头开始编写的，因为源代码在任何方面都不是CryptoAPI代码的派生代码，所以它们必须通过自己的NIST认证。现在完全有道理了。再次感谢。谢谢你问这个问题。我想问一个问题，为什么在.NET中有这么多不同的加密类至少有3个实现，但这不仅提供了“一个”原因，如果不是，“这个”原因。虽然我甚至没有从FIPS合规性的角度来考虑这些类，但多亏了你的帖子和Eugene的回答，我知道这些信息肯定要求我使用CryptoAPI变体——thx。