我一直致力于使我们的.NET应用程序符合FIPS，并且发现Managed加密类（例如AESManaged）不符合FIPS标准。我已经阅读了其他几篇关于哪些类符合的文章和问题，例如When will C# AES algorithm be FIPS compliant?和http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/e0b4493f-6e20-4b75-a118-6b6e5d26a2a6。看起来CryptoServiceProvider类与ARE FIPS兼容，但Managed类不是。
我只是想知道是否有人可以解释CryptoServiceProvider类和Managed类之间的区别？如果有人可以解释为什么CryptoServiceProvider类符合FIPS，但托管类不符合，那么我可以向老板解释为什么我必须重写我们的加密方法。引擎盖下它们根本不同吗？或者MS有没有让Managed类获得NIST认证？如果Managed类只包装CryptoServiceProvider类，那么为什么Managed类不能自动符合FIPS？如果我编写一个类将FIPS兼容类包装到我自己更容易使用的类中，我的软件是否不再符合FIPS？
感谢。
答案 0 :(得分：5)
“FIPS兼容”是错误的术语 - 您正在谈论FIPS认证的术语。不同之处在于，如果算法需要与参考实现和第三方实现兼容，那么它需要符合描述此算法的相应FIPS。但认证是另一回事。
CryptoServiceProvider类调用CryptoAPI（非托管Windows API）来执行实际的加密操作，一些CryptoAPI模块通过FIPS认证（用于商业目的）。显然，没有足够的理由来认证.NET托管类 - 如果您需要经过认证的模块，请使用CryptoAPI。认证需要大量的时间，精力和大量的资金。
此外，我猜可能有技术原因导致托管模块无法通过认证，但这只是猜测。可能会发生.NET（IL和虚拟机）的性质与认证过程中定义的某些要求相矛盾，即它们无法被认证。
至于你自己的包装类 - 有几家公司提供人员培训和认证。他们还提供咨询服务。我希望有这样服务的人在这里作出回应，但如果你需要，也可以联系他们。