4

我一直致力于使我们的 .NET 应用程序符合 FIPS，并且发现ManagedCryptography 类（例如AESManaged）不符合 FIPS。我已经阅读了其他几篇关于哪些类符合要求的文章和问题，例如C# AES 算法何时符合 FIPS？和http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/e0b4493f-6e20-4b75-a118-6b6e5d26a2a6。看起来 CryptoServiceProvider 类符合 FIPS，但托管类不符合。

我只是想知道是否有人可以解释CryptoServiceProvider类和Managed类之间的区别？如果有人可以解释为什么这些CryptoServiceProvider类符合 FIPS，但托管类不符合，那么我可以向我的老板解释为什么我必须重写我们的加密方法。它们在底层有根本不同吗？还是 MS 只是没有对托管课程进行 NIST 认证？如果Managed类只是包装CryptoServiceProvider类，那么为什么这些Managed类不自动符合 FIPS 标准？如果我编写一个类来将符合 FIPS 的类包装成我自己的更易于使用的类，我的软件是否不再符合 FIPS？

谢谢。

4

1 回答 1

6

“符合 FIPS 标准”是错误的术语 - 您说的是 FIPS 认证的。不同之处在于，如果算法需要兼容参考实现和第三方实现，则需要符合描述该算法的相应 FIPS。但认证是另一回事。

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

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

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

于 2010-10-29T16:58:51.883 回答