3 Configuring an Application to Achieve FIPS 140 Compliance with Jipher

To achieve FIPS 140 compliance, your applications must use only FIPS-approved or NIST-recommended cryptography provided by CMVP-certified cryptographic modules. However, none of the providers included in the JDK are CMVP-certified.

Configure your application to achieve FIPS 140 compliance with Jipher by following these following these steps:

Note:

If you haven't already done so, download and deploy Jipher as described in Downloading and Deploying Jipher.

  1. Register Jipher and other security providers required by the JCA and your application as described in Provider Registration:

    1. Registering Jipher as the Most Preferred Provider: It's recommended that you register Jipher as the most preferred provider, in position 1 in the list of security providers.

    2. Registering the SUN and SunRsaSign Providers for JAR File Signature Verification: The JCA requires the SUN and SunRsaSign providers for JAR file signature verification. The JDK requires this when a provider is first used to perform an encryption operation.

      Note:

      The JCA requires a non-FIPS 140 allowed algorithm, the MD5withRSA Signature algorithm, as a prerequisite for JAR file signature verification. The SunRsaSign provider provides it.

      With regards to FIPS 140 compliance, the MD5withRSA Signature algorithm is used internally for a non-security-relevant purpose and is acceptable in this instance.

    3. Registering Other Security Providers: This section lists non-cryptographic and cryptographic engine class algorithms not supported by Jipher, which your application might require, and some guidance about registering the security providers that provide these algorithms.

    You can register a provider included in the JDK as long as it's not used to provide a cryptographic engine class algorithm. (See The Java Cryptographic Architecture (JCA), Engine Classes, and Providers.) However, it can be difficult to ensure that registering one will not cause it to be used to provide a cryptographic engine class algorithm. For instance, third-party dependencies and providers themselves can use other registered providers to provide cryptographic engine class algorithms. It's therefore good practice to only register providers required by your application. One option is to register a provider and then unregister it once your application no longer needs it. See Registering the SUN and SunRsaSign Providers for JAR File Signature Verification for an example.

  2. If you're using the SunJSSE provider, which enables secure Internet communications by providing implementations of the SSL, TLS, and DTLS protocols, then follow the steps described in Configure the SunJSSE Provider to Select Jipher to Provide Cryptography. The SunJSSE provider doesn’t provide its own cryptographic engine class algorithms for these protocols. Instead, it uses the JCA to request implementations of cryptographic engine class algorithms from other providers. These steps ensure that the SunJSSE provider uses cryptographic engine class algorithms provided by Jipher and no other provider.

  3. In your application code, ensure that Jipher is the only security provider used to provide cryptography. Follow the guidance in these sections:

    Note:

    If your application, as opposed to the JCA as described in the previous note, requires a non-FIPS 140 allowed algorithm, then to achieve FIPS 140 compliance, you must change your application to no longer use that non-FIPS 140 allowed algorithm.

  4. If required, configure some of Jipher's features through system properties. See Configuring Jipher Through System Properties.

Provider Registration

To use a security provider that's not included in the JDK, such as Jipher, you must register it so that the JCA can access its security services. You can register a provider statically or dynamically.

Registering Jipher as the Most Preferred Provider

It's recommended that you register Jipher as the most preferred provider, in position 1 in the list of security providers.

When an application requests an instance of an algorithm, without specifying which provider should provide the implementation, the JCA searches the list of registered providers in preference order. The JCA returns the implementation from the first provider supplying the algorithm. Registering Jipher as the most preferred provider ensures that the JCA will select it to provide certified implementations of algorithms allowed by FIPS 140 standards.

Note:

Registering Jipher as the most preferred provider does not guarantee that it will be selected to provide an implementation of an algorithm. The following are some reasons why Jipher might not be selected:

  • The algorithm is not approved or allowed by FIPS 140 standards.

  • The application wants to initialize the algorithm with a parameter not allowed by FIPS 140 standards because, for example, the key size is too weak or the algorithm parameters are not approved.

  • The application wants to use the algorithm for an operation not allowed by FIPS 140 standards, for example, using SHA-1 to digest data to be signed or using RSA (with PKCS #1 padding) for key transport.

  • The algorithm is approved or allowed by FIPS 140 standards but Jipher doesn't provide an implementation of it.

    For example, the SUN provider provides implementations of algorithms that are approved or allowed by FIPS 140 standards that Jipher doesn't provide. These include:

    • Truncated digests such as SHA-512/224, SHA-512/256, SHA512/224withDSA, and SHA512/256withDSA
    • Signature algorithms that use SHA3, which include SHA3-224withDSA, SHA3-256withDSA, SHA3-384withDSA, and SHA3-512withDSA

    As a result, the SUN provider (or another registered provider that doesn't provide FIPS 140 validated cryptography) should be selected to provide an implementation of an algorithm that is approved or allowed by FIPS 140 standards even though Jipher is registered as the most preferred provider.

    See Registering Other Security Providers for a list of algorithms that the SUN provider supports that aren't supported by Jipher.

You register a provider like Jipher in the following ways:

  • Statically by specifying it in the list of registered providers in the java.security file
  • Dynamically by calling either the addProvider or insertProviderAt method in the java.security.Security class in your application code

See Step 8.1: Configure the Provider in How to Implement a Provider in the Java Cryptography Architecture in Java Platform, Standard Edition Security Developer's Guide for steps on how to do this.

Note:

It might be more fragile to register Jipher statically than dynamically. The following describes how Jipher could be configured incorrectly and result in Jipher not being used as expected. Of greatest concern is that this consequence might not be readily apparent. Your application still works and doesn't report any errors, but it's not using Jipher or FIPS 140 certified cryptography.
  • Suppose the Jipher provider classes are not available to a JVM instance because, for example, the jipher-jce-10.35-se.jar JAR file is not in the class path. As a result, the JVM instance will silently fail to register Jipher when configured to statically register it. The JVM instance will behave as though it wasn't configured to statically register Jipher. This will in turn impact your application's FIPS 140 compliance.
  • If the JDK's java.security file has been edited to statically register Jipher, then it might need to be re-edited if the JDK was reinstalled.

The following example is an excerpt from the java.security file. It registers Jipher in position 1 by specifying its provider class, com.oracle.jipher.provider.JipherJCE. It also registers the SUN provider in position 2, SunRsaSign in position 3, and SunJSSE in position 4: 

security.provider.1=JipherJCE
security.provider.2=SUN
security.provider.3=SunRsaSign
security.provider.4=SunJSSE
# Other registered providers follow...

Note:

The list of statically registered providers is often longer. A more complete list better ensures that a requested algorithm that is not supported by Jipher will be provided by another provider.

In this example, because Jipher is registered at position 1, the JCA will retrieve cryptographic engine class algorithm implementations from it first. If the JCA can't retrieve an implementation of a requested algorithm from Jipher, it will attempt to retrieve an implementation from one of the other registered providers. For example a request for the MD5 message digest algorithm, which is not a FIPS 140 allowed algorithm, would result in the JCA retrieving the implementation provided by the SUN provider.

Registering the SUN and SunRsaSign Providers for JAR File Signature Verification

You must register the SUN and SunRsaSign providers because they provide algorithms, which Jipher doesn't provide, that are required for JAR file signature verification.

Security providers, like Jipher, that provide algorithms for engine classes from the javax.crypto package must be in a signed JAR file. The verification of a JAR file's signature occurs when getting an algorithm instance from a class in the javax.crypto package. If JAR file signature verification fails, then the provider is not selected to provide the implementation.

JAR file signature verification requires two algorithms that Jipher doesn't provide:

  • The X.509 CertificateFactory algorithm provided by the SUN provider
  • The MD5withRSA Signature algorithm provided by the SunRsaSign provider

These algorithms must be provided by a registered provider prior to verifying Jipher's JAR file signature. Do this by registering the SUN and SunRsaSign providers.

If you want to minimize the number of registered providers in your application, you can statically register the providers that are required for JAR file signature verification, then dynamically unregister them once Jipher's JAR file signature is verified. The following example demonstrates this: 

static {
    // Dynamically register the "JipherJCE" provider if it has not already been statically registered.
    if (Security.getProvider("JipherJCE") == null) Security.insertProviderAt(new JipherJCE(), 1);

    // Trigger the javax.crypto.JarVerifier's certificate verification self-test.
    // This assumes that the "SUN" and "SunRsaSign" providers have been statically registered.
    Cipher.getInstance("AES", "JipherJCE");
 
    // Dynamically unregister the "SUN" and "SunRsaSign" providers
    Security.removeProvider("SUN");
    Security.removeProvider("SunRsaSign");
}

Registering Other Security Providers

As described in The Java Cryptographic Architecture (JCA), Engine Classes, and Providers, some providers included in the JDK provide both cryptographic engine class algorithms and non-cryptographic engine class algorithms. However, Jipher doesn't provide any non-cryptographic engine class algorithms.

In addition, the SUN and SunRsaSign providers are needed for provider JAR file signature verification. The JDK requires this when a provider is first used to perform an encryption operation. See Registering the SUN and SunRsaSign Providers for JAR File Signature Verification.

However, the fewer security providers that are registered, the lower the chance that a provider other than Jipher will be selected to provide a cryptographic engine class algorithm that Jipher doesn't support (due to FIPS 140 restrictions) or, in the case of delayed provider selection (see Delayed Provider Selection), a cryptographic engine class algorithm that Jipher does support initialized with a Key it does not support (due to FIPS 140 restrictions).

The SUN provider is optionally required to provide support for the following non-cryptographic engine class algorithms:

The SunJSSE provider is optionally required to provide TLS support through these non-cryptographic engine class algorithms:

Note that the SUN and SunRsaSun providers support cryptographic engine class algorithms that are supported by Jipher. Consequently, if you register these providers, it's important that Jipher is registered with a higher preference than them as described in Registering Jipher as the Most Preferred Provider.

The SUN provider supports the following cryptographic engine class algorithms that are not supported by Jipher:

  • KeyFactory:
    • HSS/LMS
  • MessageDigest:
    • MD2
    • MD5
    • SHA-512/224
    • SHA-512/256
  • Signature:
    • HSS/LMS
    • NONEwithDSAinP1363Format
    • SHA1withDSAinP1363Format
    • SHA224withDSAinP1363Format
    • SHA256withDSAinP1363Format
    • SHA384withDSAinP1363Format
    • SHA512withDSAinP1363Format
    • SHA3-224withDSA
    • SHA3-256withDSA
    • SHA3-384withDSA
    • SHA3-512withDSA
    • SHA3-224withDSAinP1363Format
    • SHA3-256withDSAinP1363Format
    • SHA3-384withDSAinP1363Format
    • SHA3-512withDSAinP1363Format

The SunRsaSign provider supports the following Signature engine class algorithms that are not supported by Jipher:

  • MD2withRSA
  • MD5withRSA
  • SHA512/224withRSA
  • SHA512/256withRSA
  • SHA3-224withRSA
  • SHA3-256withRSA
  • SHA3-384withRSA
  • SHA3-512withRSA

The SunJSSE provider does not support any cryptographic engine class algorithms not supported by Jipher.

Delayed Provider Selection

Java cryptographic API classes that generate, import, or can be initialized with a key (KeyGenerator, KeyPairGenerator, KeyFactory, SecretKeyFactory, Cipher, KeyAgreement, Mac, and Signature) support delayed provider selection. A getInstance(String algorithm) method call compiles a preference ordered list of providers that support the algorithm. Later, when the init method is called, the first provider in the compiled preference ordered list of providers that also supports the key (with regards to size and format) is selected.

Configure the SunJSSE Provider to Select Jipher to Provide Cryptography

The SunJSSE provider enables secure Internet communications by providing implementations of the SSL, TLS, and DTLS protocols. It doesn’t provide its own cryptographic engine class algorithms for these protocols. Instead, it uses the JCA to request implementations of cryptographic engine class algorithms from other providers. Follow these configuration steps to ensure that the SunJSSE provider uses cryptographic engine class algorithms provided by Jipher and no other provider:

  1. Permit Access to Internal JDK API Classes: This ensures that Jipher is allowed to provide cryptography requested by the SunJSSE provider.
  2. Registering Jipher as the Most Preferred Provider: This ensures that Jipher will be chosen ahead of any other providers to provide an implementation of any algorithm it supports. Also, register the SUN and SunRsaSign providers as described in Registering the SUN and SunRsaSign Providers for JAR File Signature Verification.
  3. Limit Protocol Versions, Cipher Suites, Key Material, and Named Groups: This ensures that the SunJSSE provider never requests cryptography that Jipher does not support.

These steps combined ensure that the SunJSSE provider never uses any cryptography provided by a non-FIPS 140 certified registered provider.

Note:

If the following is true about your environment, then you only have to follow the steps Permit Access to Internal JDK API Classes and Configure SSLContext with Key Material That Provides at Least 112-Bits of Security:
  • You're using JDK 21.
  • It uses a standard JDK security property configuration where:
    • The jdk.certpath.disabledAlgorithms security property specifies MD2 and MD5.
    • The jdk.tls.disabledAlgorithms security property specifies SSLv3, TLSv1, TLSv1.1, and MD5withRSA.
  • Jipher is registered as the most preferred provider and the only other registered providers are SUN, SunRsaSign, and SunJSSE. See Registering Jipher as the Most Preferred Provider.

Permit Access to Internal JDK API Classes

When a security provider provides the cryptography required by the SunJSSE to provide TLSv1.2, it must access internal JDK API classes.

If Jipher attempts to access them, an IllegalAccessException is thrown. To prevent this from happening, add one of the following command-line options when you run your Java application depending on where you specified the Jipher JAR file

  • On the class path:

    --add-exports=java.base/sun.security.internal.spec=ALL-UNNAMED

  • On the module path:

    --add-exports=java.base/sun.security.internal.spec=com.oracle.jipher

Limit Protocol Versions, Cipher Suites, Key Material, and Named Groups

This section describes which SunJSSE parameters and properties to limit to the same levels and values as Jipher. This ensures that the SunJSSE provider never requests cryptography that Jipher does not support.

Ensure That Clients and Servers Only Use TLS 1.2 and TLS 1.3

Ensure that the security property jdk.tls.disabledAlgorithms includes the values SSLv3, TLSv1, and TLSv1.1.

In addition, ensure that the system properties jdk.tls.server.protocols and jdk.tls.client.protocols contain the values TLSv1.2 and TLSv1.3. See Customizing JSSE in Java Platform, Standard Edition Security Developer's Guide for more information about these system properties and other properties you can specify to customize JSSE.

In your code, call SSLContext.getInstance("TLS") instead of supplying specific TLS protocol versions.

Note:

Calling SSLContext.getInstance("TLS1.3") sets the ceiling for protocol versions. As a result, this statement returns a context that allows TLS 1.0 and TLS 1.1 protocol versions.
Ensure TLS Cipher Suites Use FIPS 140 Algorithms from Jipher

Depending on which TLS protocol version you want to support (TLS 1.2 or TLS 1.3), specify the cipher suites that only require FIPS 140 allowed cryptography provided by Jipher as a comma-separated list for the system properties jdk.tls.client.cipherSuites and jdk.tls.server.cipherSuites. See Specifying Default Enabled Cipher Suites in Java Platform, Standard Edition Security Developer's Guide for more information about these system properties.

See The SunJSSE Provider in Java Platform, Standard Edition Security Developer's Guide for a complete list of supported cipher suites.

TLS 1.2 cipher suites are expressed as follows:

TLS_<key exchange algorithm>_<authentication algorithm>_WITH_<cipher algorithm>_<cipher strength>_<cipher mode>_<HASH or MAC>

TLS 1.3 cipher suites are expressed as follows:

TLS_<cipher algorithm>_<cipher strength>_<cipher mode>_<HASH or MAC>

The following table lists the values within a cipher suite's name that are supported by Jipher:

Table 3-1 Values Within a Cipher Suite's Name Supported by Jipher

Component Supported Supported but Not Recommended
Key exchange algorithm ECDHE, DHE DH
Authentication algorithm ECDSA, RSA DSS
Cipher algorithm AES —
Cipher strength 256, 128 —
Cipher mode GCM CBC
HASH or MAC SHA384, SHA256 SHA

Cipher suites that use RSA for key exchange and authentication are expressed as follows:

TLS_RSA_WITH_<cipher algorithm>_<cipher strength>_<cipher mode>_<HASH or MAC>

These cipher suites are not supported.

See "Appendix D—RSA Key Transport" in NIST SP 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations for the reasons why these cipher suites are not supported. In short, it is because RSA key transport as used in TLS versions 1.0 through 1.2 is implemented using the PKCS #1 v1.5 padding scheme.

Configure SSLContext with Key Material That Provides at Least 112-Bits of Security

Key managers are responsible for managing the key material which is used to authenticate the local TLS endpoint to its peer. Configure your key manager with key material with the following parameters so that the key material provides at least 112-bits of security:

  • RSA: Modulus >= 2048
  • DSA: (L, N) = (2048, 224), (2048, 256) or (3072, 256)
  • EC: secp224r1, secp256r1, secp384r1, or secp521r1

See the section KeyManagerFactory Class in Java Platform, Standard Edition Security Developer's Guide.

Note:

The system property jdk.tls.disabledAlgorithms has no impact on key size used by the local TLS endpoint to generate a digital signature to authenticate itself to its peer.

While jdk.tls.disabledAlgorithms=DSA, disables DSA (disables DSS cipher suites), jdk.tls.disabledAlgorithms=DSA keySize < 2048 neither disables DSS cipher suites nor does it prevent the local TLS endpoint from using a DSA private key of less than 2048 bits when generating a signature to authenticate itself to its peer.

Configure the Size of Ephemeral Diffie-Hellman Keys

Set the system property jdk.tls.ephemeralDHKeySize to 2048.

Ensure the JSSE Only Uses FIPS 140 Approved Named Groups

FIPS 140 compliance requires the use of approved elliptic curves and safe-prime groups for key establishment as documented in "Appendix D: Approved ECC Curves and FFC Safe-prime Groups" in NIST SP 800-56A Rev. 3: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography.

Set the system property jdk.tls.namedGroups to only allow the following:

  • FIPS 140 approved named curves:
    • secp256r1
    • secp384r1
    • secp521r1
  • FIPS 140 approved FFC safe-prime Groups:
    • ffdhe2048
    • ffdhe3072
    • ffdhe4096

Explicitly Selecting Jipher to Provide Cryptography

When an application calls getInstance from an engine class such as MessageDigest, Signature, KeyFactory, KeyPairGenerator, or Cipher to acquire an instance of a cryptographic engine class algorithm, it can explicitly specify which provider should provide the algorithm by calling one of the following:

  • getInstance(String algorithm, String provider)
  • getInstance(String algorithm, Provider provider)

One way to ensure that Jipher is the only security provider used to provide cryptography is to explicitly specify that Jipher provide the instance of the algorithm in all getInstance method calls used to acquire an instance of a cryptographic engine class algorithm, for example: 

Cipher.getInstance("AES", "JipherJCE");

In practice, this is often infeasible because of the following:

  • Applications often need to use other security providers to provide higher level functionality, and these providers will internally make getInstance(String algorithm) calls to acquire the cryptographic engine class algorithms they need to deliver the higher level functionality they provide. For example the PKCS12 KeyStore algorithm provided by the SUN provider internally uses other security providers to provide the cryptographic engine class algorithms it uses to secure the key store.
  • Applications often use third-party libraries that internally make getInstance(String algorithm) calls to acquire cryptographic engine class algorithms they need to deliver the functionality they provide.

Consequently, if your application, or one of its dependencies, calls getInstance(String algorithm) from an engine class, then configure the JVM so that Jipher is implicitly selected to provide the algorithm. See Implicitly Selecting Jipher to Provide Cryptography.

Implicitly Selecting Jipher to Provide Cryptography

To implicitly select Jipher whenever an application or one of its dependencies calls an engine class's getInstance(String) method, follow these steps:

  1. Register Jipher as the most preferred provider. See Provider Registration.
  2. Configure your application and its dependencies to only request cryptographic engine class algorithms that Jipher supports. For example, if you're using the SunJSSE provider to provide secure Internet communications, then follow the steps described in Configure the SunJSSE Provider to Select Jipher to Provide Cryptography. If your application requires a non-FIPS 140 allowed algorithm, then to achieve FIPS 140 compliance, you must change your application to no longer use that non-FIPS 140 allowed algorithm.

Configuring Jipher Through System Properties

You can configure some of the features of Jipher through the following system properties:

Table 3-2 Jipher System Properties

System Property Description Default Value
java.security.debug

Standard Java system property.

If the value includes jipher or all, then debug logging through System.err is enabled within Jipher. This prints debugging information, including the library loading steps that are performed when Jipher is first used.

None
java.io.tmpdir

Standard Java system property.

This system property specifies the location of temporary files.

Jipher uses this value as the default location in which to create temporary directories for storing native libraries. See jipher.user.dir.

Typically /tmp on Linux operating systems
jipher.user.dir

Specifies the path location that Jipher uses to create temporary directories to store library files. The user running the JVM process must have write access to this directory when using Jipher. In addition, this directory cannot be on a file system mounted with the noexec option.

Note:

Sometimes the /tmp directory is mounted with the noexec option. If this is the case, then set the jipher.user.dir system property to another directory that has write access and is on a file system that has not been mounted with the noexec option.
The value of java.io.tmpdir, typically /tmp on Linux operating systems
jipher.fips.enforcement

Specifies the FIPS 140 enforcement policy to be applied at the Java security provider layer. It can have one of the following values:

  • FIPS: Approved algorithms and key lengths are permitted in accordance with how they are used. Legacy use is permitted.
  • FIPS_STRICT: Only algorithms and key lengths with Acceptable approval status are permitted.
  • NONE: No additional enforcement is performed; any enforcement implemented in OpenSSL is still applied. This policy is intended to be used during preproduction debugging. You may encounter behavior that differs from the other policies such as:
    • A different exception being thrown
    • A delay in an exception being thrown; for example, an exception may be thrown when a signature object is used instead of when it is created or initialized

Acceptable is used by NIST to mean that the algorithm and key length is safe to use.

Legacy use means that the algorithm or key length may be used only to process already protected information, for example, to decrypt ciphertext data or to verify a digital signature. See NIST SP 800-131A Rev. 2: Transitioning the Use of Cryptographic Algorithms and Key Lengths and FIPS 140 Enforcement Policy for more information.

FIPS
jipher.fips.deactivateSecurityPatches Specifies whether Jipher prioritizes security (false) or compliance (true).

The Jipher JAR file embeds two copies of the OpenSSL FIPS module for each supported platform:

  • A version of the OpenSSL FIPS module built from source code that has been tested by a CSTL, validated by the CMVP, and issued a FIPS 140 validation certificate
  • A version of the OpenSSL FIPS module built from the FIPS 140 compliant baseline source code with additional security patches applied, which is used by default

The system property jipher.fips.deactivateSecurityPatches can have one of the following values:

  • false: Jipher prioritizes security over compliance. It uses the OpenSSL FIPS module with the additional security patches to implement all the cryptography it provides.
  • true: Jipher prioritizes compliance over security. It uses the OpenSSL FIPS module without the additional security patches.

Caution:

Setting jipher.fips.deactivate.security.patches to true incurs the serious risk that security vulnerabilities, published as Common Vulnerabilities and Exposures (CVE) in the public domain, will become exploitable in your deployment.

However, any change to the OpenSSL FIPS module following FIPS 140 validation renders it non-compliant, so Jipher's default operation, setting jipher.fips.deactivate.security.patches to false, is not strictly FIPS 140 compliant with FISMA. Some users prefer to be strictly FIPS 140 compliant and use the CSTL-tested and CMVP-validated OpenSSL FIPS module that has been issued a FIPS 140 validation certificate. Others, like Oracle, use a recent baseline of the OpenSSL FIPS module that is FIPS 140 compliant, add security patches, and disclose this choice to customers and auditors. Regardless of whether you choose to be strictly FIPS 140 compliant or use the OpenSSL FIPS module with the additional security patches, Oracle recommends disclosing this choice to customers and auditors.

false

FIPS 140 Enforcement Policy

Jipher can perform enforcement of FIPS 140 algorithm usage and key sizes according to how the algorithm and key is being used.

You can specify a FIPS 140 enforcement policy with the jipher.fips.enforcement system property. See Configuring Jipher Through System Properties. The default policy, FIPS, permits legacy use. This means that an algorithm or key length with "legacy use" status may be used, but only to process already protected information, for example, to decrypt ciphertext data or to verify a digital signature. The FIPS_STRICT policy only permits algorithms and key lengths with Acceptable approval status. This is more restrictive though likely to be more stable over time. See NIST SP 800-131A Rev. 2: Transitioning the Use of Cryptographic Algorithms and Key Lengths for more information..

In general, the default FIPS policy is similar to the FIPS_STRICT policy except that the FIPS_STRICT policy requires longer key lengths for digital signature verification and MACs for various algorithms. The following table highlights these differences in bold.

Table 3-3 Minimum Key Lengths of the Default FIPS Policy and the FIPS_STRICT Policy

Rule FIPS Policy FIPS_STRICT Policy

AES key bits

>= 128 for symmetric encryption and decryption

>= 128 for symmetric encryption and decryption

DESede key bits

Not supported for symmetric encryption

= 192 for symmetric decryption

Not supported for symmetric encryption and decryption

DH key bits

>= 2048 for key generation and key agreement

>= 2048 for key generation and key agreement

DSA parameter bits

(prime size, sub-prime size) is one of (2048, 224), (2048, 256) or (3072, 256) for key generation and signature generation

(prime size, sub-prime size) is one of (2048, 224), (2048, 256) or (3072, 256) for key generation and signature generation and verification

DSA parameter bits

prime size > 512 bits for signature verification

See the previous table cell in this column

EC curve bits

>= 224 for key generation, signature generation and key agreement

>= 224 for key generation, signature generation, verification, and key agreement

EC curve bits

>= 160 for signature verification

See the previous table cell in this column

HMAC key bits

>= 0 for MAC

>= 112 for MAC

Message digest algorithm

!= SHA-1 for signature generation

!= SHA-1 for signature generation and verification

RSA key bits

>= 2048 for asymmetric encryption and decryption key generation and signature generation

>= 2048 for asymmetric encryption and decryption key generation and signature generation and verification

RSA key bits

>= 1024 for signature verification.

See the previous table cell in this column

RSA padding

!= PKCS1 for asymmetric encryption

!= PKCS1 for asymmetric encryption