FIPS compliance of the .Net crypto API, something I never thought a client would be bothered about.  Right?

Of course, I was wrong.

A client, whose system I was reviewing late last year, wanted to use FIPS compliant .NET crypto APIs due to reasons not directly related to security as it turns out (it was in support of a claim in their patent application).

The client intended to use the AES encryption in the CBC mode, a 256-bit key, and a randomized IV.  All good stuff.  The not-so-good stuff, however, was the use ofRijndaelManaged class in the System.Security.Cryptography module for the AES encryption.  The RijndaelManaged class implements the Rijndael algorithm and can be used for the AES encryption in some restrictive cases. As it turns out, the .NET class library containing this class is not FIPS compliant.

First and foremost, what is the difference between AES and Rijndael?

AES and Rijndael
AES is a standard; Rijndael is an algorithm.

When NIST wanted an alternative to DES (3-DES) algorithms, they requested proposals for algorithms that would be the new AES standard. The winning algorithm had to support key sizes of 128, 192, and 256 bits, and a block-size of 128 bits. The Rijndael algorithm won and its specific implementation (with block-size/key-length restrictions) was adopted as the AES standard. Whereas, Rijndael allows for both key and block-sizes to be chosen independently from the set of {128, 160, 192, 224, 256} bits, AES is a Rijndael implementation that allows key sizes from {128, 192, 256} bits and the block-size of 128 bits.

FIPS-197 publication has the gory details of the AES specification.

What is FIPS compliance?
Any cryptographic implementation module (usually a library) can be certified for FIPS compliance within the Cryptographic Module Validation Program (CMVP).  FIPS compliance guarantees that if an implementation is certified, algorithms within it (say AES) will comply with the standard specification and therefore will be interoperable with other standard implementations.

In the land of .NET, there are many ways to perform AES encryption, unfortunately, not all of them are FIPS compliant.

• AESCryptoServiceProvider in the System.Security.Cryptography module: This class uses Windows CryptoAPI (CAPI) which uses RSAENH.DLL which is FIPS-compliant. In the .NET world, this is the best option for using AES in any mode of operation (e.g. CBC, CFB, OFB).
• RijndaelManaged in the System.Security.Cryptography module:  This module is not FIPS compliant.  However, this class can be used to perform AES encryption in CBC mode only if the block-size is set to 128 bits and key length is in {128, 192, 256} bits. Due to feedback size issues, this class cannot be used to perform encryption in CFB/OFB modes. In essence, do not use this class unless you want to support block-sizes other than 128 bits.
• AESManaged in the System.Security.Cryptography module: This is just a wrapper for the RijndaelManaged class where the block-size is fixed to 128 bits.   Obviously, this is not FIPS compliant and is only good for the CBC mode encryption of AES.  As anticipated, it does not support the feedback size and therefore cannot be used for CFB or OFB modes of AES.  Do not use this class.

If you turn on the registry flag
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy
only the FIPS compliant .NET crypto classes will work. In general, none of the classes ending with “Managed” will work since none of them, at least so far, are FIPS compliant.

In conclusion,

• If FIPS compliance is required turn on the registry flag referenced in the previous paragraph
• For AES encryption, always use the AESCryptoServiceProvider class
• Do not use AESManaged or RijndaelManaged unless you require a block size other than 128 bits.