none
AesCryptoServiceProvider and FIPS mode RRS feed

Answers

  • Hi,


    Strictly speaking it's not the AesCryptoServiceProvider that is FIPS 140-2 compliant, but the underlying libraries accessed through the CAPI (like the Enhanced Cryptographic Provider in rsaenh.dll). All other .NET CSPs, e.g. AesManaged or MD5CryptoServiceProvider, that do not rely on this libraries are not compliant.

    The security policy FIPS mode simply turns on a flag in the registry (HKLM\SYSTEM\CurrentControlSet\Control\Lsa\fipsalgorithmpolicy), nothing more. It is the responsibility of CSPs to check this flag. The AesManaged class for example checks the flag in its constructor and if it's set it simply returns an InvalidOperationException that tells the user that this is not a FIPS compliant algorithm (because it doesn't call into the compliant libraries).

    Turning the flag in the registry on enforces the use of FIPS compliant algorithms, but does not trigger any other system-side processing. By enabling this flag, you'll get an exception every single time an application attempts to use a non-compliant algorithm. Since rsaenh.dll is FIPS compliant, the AesCryptoServiceProvider will not throw such an exception. After all, it is only a thin wrapper around the CAPI (advapi32.dll, crypt32.dll).

    See also: http://blogs.msdn.com/shawnfa/archive/2005/05/16/417975.aspx


    Marcel
    • Marked as answer by ksmitha Monday, February 1, 2010 1:55 PM
    Friday, January 29, 2010 10:21 AM
  • Smitha,

    AFAIK, the AesCryptoServiceProvider has not been tested by NIST. So, strictly speaking, the .NET wrapper side can't be FIPS 140-2 compliant. But the called, underlying libraries, i.e. the implementation of the algorithms, have been certified.

    As already told in my previous post, turning the security policy FIPS mode on has absolutely no influence on the FIPS compliancy. It merely ensures that software using this flag is informed about the current security policy and can, should, but isn't forced to take any measures whatsoever.


    Marcel
    • Marked as answer by ksmitha Monday, February 1, 2010 1:54 PM
    Saturday, January 30, 2010 8:04 AM

All replies

  • Hi,


    Strictly speaking it's not the AesCryptoServiceProvider that is FIPS 140-2 compliant, but the underlying libraries accessed through the CAPI (like the Enhanced Cryptographic Provider in rsaenh.dll). All other .NET CSPs, e.g. AesManaged or MD5CryptoServiceProvider, that do not rely on this libraries are not compliant.

    The security policy FIPS mode simply turns on a flag in the registry (HKLM\SYSTEM\CurrentControlSet\Control\Lsa\fipsalgorithmpolicy), nothing more. It is the responsibility of CSPs to check this flag. The AesManaged class for example checks the flag in its constructor and if it's set it simply returns an InvalidOperationException that tells the user that this is not a FIPS compliant algorithm (because it doesn't call into the compliant libraries).

    Turning the flag in the registry on enforces the use of FIPS compliant algorithms, but does not trigger any other system-side processing. By enabling this flag, you'll get an exception every single time an application attempts to use a non-compliant algorithm. Since rsaenh.dll is FIPS compliant, the AesCryptoServiceProvider will not throw such an exception. After all, it is only a thin wrapper around the CAPI (advapi32.dll, crypt32.dll).

    See also: http://blogs.msdn.com/shawnfa/archive/2005/05/16/417975.aspx


    Marcel
    • Marked as answer by ksmitha Monday, February 1, 2010 1:55 PM
    Friday, January 29, 2010 10:21 AM
  • Marcel,
    Thank you for your response. My biggest confusion had been with with AesCryptoServiceProvider used in non-FIPS mode.
    After reading the technet article listed as a second link in my reference section of previous email,
    I had not been clear if using AesCryptoServiceProvider in non FIPS mode would be FIPS 140-2 compliant or not.
    I had it clarified by using an issue with MS techSupport.
    The answer is AesCryptoServiceProvider is FIPS 140-2 compliant when used in FIPS and non FIPS mode.

    Following is the response I got from the microsoft professional. I am copy pasting it for others who have been looking for this info.

    -------------------------------------------------------------
    Before going into the details please see my blog at the link

     

    http://blogs.msdn.com/winsdk/archive/2009/11/04/is-rijndaelmanaged-class-fips-complaint.aspx.
    AesCryptoServicePriovider class is FIPS complaint and it works both with FIPS policy enabled as well as disabled.

    Points to note from the blog

    FIPS compliance means the implementation of the algorithm itself has been tested by the US Government's NIST agency for all known conditions and produces the correct result. This testing helps ensure compatibility between implementations that receive validated status. Non-validated implementations have not received this testing and therefore may, or may not be 100% completely interoperable.

    On the other hand the equivalent of the same Aes algorithm was the RijindaelManaged class but it is not FIPS complaint.

    So if your question is only with AesCryptoServicePriovider then the answer is yes it will provide you with the same results with FIPS enabled and/or disabled.

    In case you have been using RijindaelManaged class then it will give you an exception if FIPS policy is enabled.
    -------------------------------------------------------------

    Smitha

    Friday, January 29, 2010 9:38 PM
  • Smitha,

    AFAIK, the AesCryptoServiceProvider has not been tested by NIST. So, strictly speaking, the .NET wrapper side can't be FIPS 140-2 compliant. But the called, underlying libraries, i.e. the implementation of the algorithms, have been certified.

    As already told in my previous post, turning the security policy FIPS mode on has absolutely no influence on the FIPS compliancy. It merely ensures that software using this flag is informed about the current security policy and can, should, but isn't forced to take any measures whatsoever.


    Marcel
    • Marked as answer by ksmitha Monday, February 1, 2010 1:54 PM
    Saturday, January 30, 2010 8:04 AM
  • Hello, it's actually the algos under the "AesManaged" (all "...Managed") class that haven't been validated by NIST via their Cryptographic Algorithm Validation Program (CAVP).
    Tuesday, July 3, 2018 11:48 AM