My organization has a group policy that is applied to servers enforcing FIPS compliance (Windows AD policy).

In .NET, HMACSHA1 is one of the encryption/hash algorithms that is FIPS compliant. I don't understand how HMACSHA256 or HMACSHA512 is not also in this FIPS compliance list. Is HMACSHA1 somehow a stronger hash than HMACSHA512? How could this be?

FIPS compliance list for .NET: http://blog.aggregatedintelligence.com/2007/10/fips-validated-cryptographic-algorithms.html


"FIPS compliance" is about more than the algorithm. It is about implementations. Being awarded the "compliant" badge is a long, complex and very expensive process; its conceptual meaning is that there are some strong reasons to believe that the implementation is correct and secure and fulfils a number of security properties. Since we don't really know how to prove that software is correct in all generality, most of FIPS compliance is done through audits and analysis of development process. This is rather thorough; this includes, for instance, making sure that during development, source code versioning was used, with proper attribution of each line of code to a properly identified developer, for whom some background checks were performed.

In practice, getting compliance implies producing a lot of paperwork (many thousands of pages) and even more auditing, for a cost that easily goes to $50000 or more, and takes up months. Costs grow up quickly with the scope. Apparently, in 2007 (from your link), Microsoft went through the whole ordeal for HMAC/SHA-1 but not for HMAC/SHA-256 or HMAC/SHA-512, which is why the former is "FIPS validated" but not the latter.

This may be related to the fact that back in that time, .NET could use the SHA-1 implementation from the Win32 layer (CryptoAPI), in native code, while SHA-256 and SHA-512 were "managed" code; doing FIPS compliance for HMAC/SHA-256 with the managed implementation (SHA256Managed) would have thrown the CLR runtime, including the JIT compiler, within the scope of the auditing, and price would have probably skyrocketed. A native implementation of SHA-256 was added in .NET 3.5 (SHA256Cng) but it was released only at the end of 2007, too late for the compliance shown in the list you link to.

  • FIPS 140 level 1 is not particularly thorough. It doesn't take all that much more than functional testing. It does involve some paperwork, but I think “only” in the hundreds of pages range. Apr 21 '16 at 18:51

There are two different notions of compliance here:

  • Using a compliant algorithm — the official term is “Approved”. Hash algorithms for HMAC are Approved if they are listed in FIPS 180-4 (or earlier versions). SHA-1, SHA-256 and SHA-512 are all FIPS Approved secure hash algorithms and the HMAC function based on them are thus FIPS Approved HMAC functions.
  • Using a compliante implementation — the official term is “validated”. To be validated, an implementation has to undergo a certification process where the code is tested and analyzed, and the product vendor has to submit the appropriate paperwork. The technical part of the validation process is not very difficult unless you go for validation levels higher than 1 (which is basically functional testing, i.e. verifying that the implementation returns the correct values), but it has to be done through the formal channels and it has to be re-done every time the code changes.

Apparently (I haven't checked), in this implementation, only the SHA-1-based functions have undergone the formal testing process, so the implementation is only validated for those functions. This is a validated implementation of HMAC-SHA-1, which is an approved algorithm. The SHA-2-based algorithms are approved, but this implementation of the algorithms is not validated.

  • <joke> so occasionally you DO have to run faster than the bear </joke> Apr 22 '16 at 6:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.