We're developing a Client/Server C# .NET application that needs to be FIPS compliant.Im reading a lot about FIPS online, but am having a bit of difficulty determining the difference between the compliance of the encryption algorithm chosen, and what data needs to be encrypted for compliance.

I understand that the following algorithms are compliant:

  • Symmetric Key
    • AES, Triple-DES, Escrowed Encryption Standard
  • Asymmetric Key
  • Hash Standards
    • SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256
  • Random number generators
  • Message authentication


However, let's pretend absolutely nothing in my software used encryption, then I would technically be fully compliant, no?

The things I can think of that would need encryption are our communications from client -> server and vice-versa, our serialized data we store on disk, and our licensing process / files.

What am I missing here?

  • 4
    If your software doesn't use any encryption, then it cannot be tested for FIPS 140 compliance. FIPS 140 applies only to cryptographic modules. If your software isn't a cryptographic module, FIPS 140 is irrelevant. If your software is used as part of a larger product that uses cryptography, then whether it will have an impact on the larger product's FIPS 140 compliance depends on what your software does. Commented Aug 13, 2013 at 17:18

1 Answer 1


FIPS140-2 deals only with the proper way by which a cryptographic module must operate and be protected from attacks. One can be just compliant with his modules, or one can be compliant AND validated with her modules. There are 4 different levels of compliance, 1 to 4, with a higher level more protective than a lower level. Getting validated is an expensive undertaking, usually done by external security labs.
FIPS140-2 does not talk about what data need to be encrypted by an application. Various standards bodies, unique to each industry segment of interest, establish the requirements, procedures and processes of data protection and encryption specific to that industry. For example, PCI DSS by the credit-card industry, HIPAA by the health care industry.
These bodies may or may not demand that an encryption module would be FIPS140-2 compliant, but certainly being such is a prudent choice - at least from a liability point of view.

Some relevant comments from infosecisland.com:

  1. "I have done FIPS 140-2 compliance tasks firsthand with: OpenSSL, OpenSSH, Sun Java 6, Apache Tomcat 5.5 and 6.0, Mozilla NSS. I can tell you that none of these modules are operating in a FIPS 140-2 compliant mode by default, getting them into a FIPS 140-2 compliant mode is not trivial, and operating in a FIPS 140-2 compliant mode is not always a good idea for compatibility reasons."

  2. "Allow me to clarify the business cases that someone will want to invest in the time and expenses necessary to achieve FIPS 140-2 validation, not just compliance: When you want to sell anything that is cryptographically relevant to the DoD or any government working group that looks to the DoD for security specifications. This is not going to be your typical enterprise customers, but specific government entities that require the assurance of cryptographic integrity that FIPS 140-2 provides."

So, if you don't have a crytographic module in your application, FIPS140-2 is not relavant to you. If you do encrypt some parts of your program, like data or a comm protocol - either because it is the proper thing to do or being required by a standards body or by customer requirements or by regulations - and you need to be FIPS140-2 compliant, that encrytion routine/module needs to either just adhere to the FIPS specs or even be fully validated.

  • 3
    Enabling FIPS mode can actually weaken security. For example new versions of OpenSSL have implemented DSA in a way that doesn't fail when the PRNG fails, but disable that feature in FIPS mode. Commented Aug 14, 2013 at 15:17

You must log in to answer this question.