我一直致力于使我们的 .NET 应用程序符合 FIPS 标准，并发现托管加密类（例如 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 ？
谢谢。
I have been working on making our .NET application FIPS compliant, and have found that the Managed Cryptography classes (such as AESManaged) are not FIPS compliant. I have read several other articles and questions on which classes are compliant, such as When will C# AES algorithm be FIPS compliant? and http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/e0b4493f-6e20-4b75-a118-6b6e5d26a2a6. It looks like the CryptoServiceProvider classes ARE FIPS compliant, but the Managed classes are not.
I am just wondering if someone can explain the difference between the CryptoServiceProvider classes and the Managed classes? And if someone can explain why the CryptoServiceProvider classes are FIPS compliant, but the Managed classes are not, so I can explain to my boss why I have to rewrite our encryption methods. Are they fundamentally different under the hood? Or has MS just not subjected the Managed classes to NIST certification? If the Managed classes just wrap the CryptoServiceProvider classes, then why aren't the Managed classes automatically FIPS compliant? And if I write a class to wrap a FIPS compliant class into a more easily usable class of my own, is my software no longer FIPS compliant?
Thanks.
发布评论
评论（1）
“符合 FIPS 标准”是一个错误的术语 - 您所说的是经过 FIPS 认证的产品。不同之处在于，如果算法需要与参考实现和第三方实现兼容，那么它需要符合描述该算法的相应 FIPS。但认证则是另一回事。
CryptoServiceProvider 类调用 CryptoAPI（非托管 Windows API）来执行实际的加密操作，并且某些 CryptoAPI 模块经过 FIPS 认证（用于商业目的）。显然没有足够的理由来认证 .NET 托管类 - 如果您需要经过认证的模块，请使用 CryptoAPI。认证需要大量的时间、精力和大量的资金。
另外，我猜想可能存在技术原因阻止托管模块获得认证，但这只是一个猜测。 .NET（IL 和虚拟机）的本质可能与为认证过程定义的某些要求相矛盾，即它们无法通过认证。
至于您自己的包装类 - 有几家公司本身提供人员培训和认证。他们还提供咨询服务。我希望此类服务的人员能够在此回复，但如果您需要，也可以联系他们。
"FIPS-compliant" is wrong term - you are talking about FIPS-certified ones. The difference is that if the algorithm needs to be compatible with reference implementation and third-party implementations, then it needs to be compliant to corresponding FIPS that describes this algorithm. But certification is a different story.
CryptoServiceProvider classes call CryptoAPI (unmanaged Windows API) to perform actual crypto operations, and some CryptoAPI modules are FIPS-certified (for business purposes). Obviously there were not enough reasons to certify .NET managed classes - if you need certified modules, use CryptoAPI ones. Certification takes lots of time, efforts and significant amount of money.
Also I guess there can be technical reasons that prevent the managed modules from certification, but this is just a guess. It can happen that the nature of .NET (IL and virtual machine) contradict to some requirements defined for certification process, i.e. they just can't be certified.
As for your own wrapper classes - there exist several companies that provide personnel training and certification itself. They also offer consulting services. I hope that somebody from such service responds here, but you can contact them as well if you need.