We have an app that makes use of Non FIPS compliant AES256 System.Cryptography calls. My question is, can Bitlocker be FIPS140 compliant on a PC, but not need the FIPS algorithm set for .NET calls?

For the U.S. Government (VA), are told we need the policy enabled for FIPS, Policy Editor --> Security Settings --> Local Policies --> Security Options --> System cryptography: Use FIPS compliant algorithm ... enabled. (We are also told this coincides with: Set the Enabled value to 1 in HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy, which is what the PC image folks are doing.)

The good news is that this changes the Bitlocker config so that Recovery passwords are not created or backed up.

The bad news is that .NET calls to Non-FIPS compliant APIs result in a hard exception: "This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms. Stack: at System.Security.Cryptography.AesManaged..ctor()" It might not be so tricky to refactor, but this actually is vendor API code, so we have to arrange with them to re-code.

I have reviewed this a few times.

As well as this: https://security.stackexchange.com/questions/152538/full-disk-encryption-and-fips

  • Further comment on this story is that it might be easier to just cut app-level encryption due to this setting and rely on the full disk encryption. This appears to be the letter of the requirement. Although this actually means just transmitting the data with only TLS encryption from the web service and storing the same non-encrypted data locally.
    – Ben Butzer
    Jul 14, 2017 at 14:18

1 Answer 1


Ultimately, we changed the app. We switched the app code to use AesCryptoServiceProvider to replace the AesManaged we had been using. AesCryptoServiceProvider uses the underlying Windows CryptoAPI to perform the encryption. AesManaged performs the encryption in pure managed code. Advantages to using AesCryptoServiceProvider include potential for higher speed and the fact that CryptoAPI is FIPS certified (AesManaged is not, and is the source of the crash). Once the Windows 10 has the FIPS encryption policy, the old encryption calls are blocked in .NET. There was much debate about whether app level encryption is necessary and no one could be pinned down. The answer that probably would satisfy auditors would be, "If you never had it before, and now FIPS140 Bitlocker is enabled, you are covered. If you did have app level encryption before, you need to replace it with a compatible compliant encryption." Side note, we verified that AesCryptoServiceProvider can decrypt the AesManaged encryption, and vice versa.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .