I never realized this before this question, but you're right. The constructor has this:
public RijndaelManaged()
{
if (Utils.FipsAlgorithmPolicy == 1)
{
throw new InvalidOperationException(Environment.GetResourceString("Cryptography_NonCompliantFIPSAlgorithm"));
}
}
System.Security.Cryptography.AesManaged has something similar:
public AesManaged()
{
if (CoreCryptoConfig.EnforceFipsAlgorithms)
{
throw new InvalidOperationException(SR.GetString("Cryptography_NonCompliantFIPSAlgorithm"));
}
this.m_rijndael = new RijndaelManaged();
this.m_rijndael.BlockSize = this.BlockSize;
this.m_rijndael.KeySize = this.KeySize;
}
Have you tried System.Security.Cryptography.AesCryptoServiceProvider? It should work since it's using the CAPI based FIPS AES implementation built into Windows.
This question on Microsoft's .NET Base Class Library forum discusses which algorithms are FIPS compliant and has good links.
It appears that Microsoft is making a consistent effort to obey the setting of HKEY_LOCAL_MACHINESystemCurrentControlSetControlLsaFIPSAlgorithmPolicy on pre-Vista machines and use of the BCryptGetFipsAlgorithmMode API for post-Vista.
I assume there is non-trivial effort involved in certifying an implementation as FIPS compliant, that is why Microsoft probably doesn't want to repeat the process and only offers the AesCryptoServiceProvider for customers that absolutely need this requirement.
This MSDN blog post has a comment that makes it clearer:
The easy way to figure out if an
algorithm is compliant or not is to
look at the suffix. None of the
*Managed types are FIPS certified. The *CryptoServiceProvider and *Cng
types however, may well be FIPS
certified. If they implement an
algorithm that FIPS allows, and are
using the default Microsoft providers,
then they will be.
For instance, SHA256Managed is not
(because it is *Managed).
SHA256CryptoServiceProvider and
SHA256Cng are.
MD5CryptoServiceProvider is not
(because MD5 is not a FIPS algorithm).
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…