1 What is Oracle Jipher?

Oracle Jipher is a Java Cryptographic Service Provider (CSP) that dynamically loads a Federal Information Processing Standards (FIPS) 140-3 validated OpenSSL cryptographic module at runtime and uses it as the underlying cryptographic implementation. It enables the deployment of Java applications in FIPS-regulated environments. Jipher makes its cryptographic services available to Java developers using the Java Cryptography Architecture (JCA).

Jipher 20 supports the following runtimes:

• Oracle JDK 27
• Oracle JDK 25
• Oracle JDK 21
• Oracle JDK 17

Jipher 20 supports the following platforms:

• Oracle Linux 10, 9, and 8 on x86-64 and aarch64
• Red Hat Enterprise Linux (RHEL) 10, 9, and 8 on x86-64 and aarch64
• macOS 26 on M series Apple silicon
• Windows Server 2025

For TLS, Jipher supports the JDK JSSE provider, in particular, the SunJSSE provider for TLSv1.2 and TLSv1.3.

Jipher, also known as JipherJCE, provides FIPS 140-3 cryptographic services by using the Foreign Function and Memory (FFM) API starting with JDK 25 and the Java Native Interface (JNI) in JDK 17 and 21 to make calls into the OpenSSL FIPS module. It maps Java cryptography API calls to OpenSSL API calls, which call into the OpenSSL FIPS module. See FIPS-140 in the OpenSSL documentation for more information.

The Java Cryptographic Architecture (JCA), Engine Classes, and Providers

The JCA is a framework for working with cryptographic services, such as digital signature algorithms, message digest algorithms, and key conversion services.

The JCA defines classes that provide the functionality of these cryptographic services. These classes are called engine classes. An engine class provides the interface to a specific type of cryptographic service, independent of a particular algorithm or provider.

The JCA includes both cryptographic engine classes, which support cryptographic algorithms and non-cryptographic engine classes, which support non-cryptographic algorithms.

Cryptographic engine classes that support cryptographic algorithms provide one of the following:

• Cryptographic operations, for example, encryption, digital signatures, and message digests; these engine classes include Cipher, Mac, KDF, KEM, KeyAgreement, MessageDigest, and Signature
• Generators or converters of cryptographic material such as keys and algorithm parameters; these engine classes include KeyGenerator, KeyFactory, SecretKeyFactory, SecureRandom, AlgorithmParameters, and AlgorithmParameterGenerator

Non-cryptographic engine classes that support non-cryptographic algorithms provide one of the following:

• Objects, such as keystores and certificates, that encapsulate cryptographic data and can be used at higher layers of abstraction; these engine classes include KeyStore, CertificateFactory, CertPathBuilder, CertPathValidator, and CertStore
• Protocols, such as TLS, and other higher level functionality that employ cryptographic operations and the objects that encapsulate cryptographic data; these engine classes include SSLContext, KeyManagerFactory, and TrustManagerFactory

A CSP, which is used interchangeably with the term "provider," is a package or set of packages that implement one or more cryptographic services. To use the JCA, an application requests a particular type of object, such as a MessageDigest, and a particular algorithm or service, such as the SHA-256 algorithm, and gets an implementation from one of the installed providers. For example, the following statement requests a SHA-256 message digest from an installed provider:

md = MessageDigest.getInstance("SHA-256");

Alternatively, the program can request objects from a specific provider. For example, the following statement requests a SHA-256 message digest from Jipher:

md = MessageDigest.getInstance("SHA-256", "JipherJCE");

See Java Cryptography Architecture (JCA) Reference Guide in Java Platform, Standard Edition Security Developer's Guide for more information.

FIPS 140

The Federal Information Processing Standards (FIPS) of the United States are a set of publicly announced standards published by the National Institute of Standards and Technology (NIST). The FIPS 140 standards detail security requirements for cryptographic modules. Accredited Cryptographic and Security Testing Laboratories (CSTLs) test that cryptographic modules meet FIPS 140 security requirements. Modules that meet these security requirements are issued a Cryptographic Module Validation Program (CMVP) certificate.

Organizations that must comply with the Federal Information Security Modernization Act (FISMA) include state agencies and private sector companies with government contracts. FISMA mandates the use of FIPS 140 approved or allowed cryptography provided by cryptographic modules with CMVP certificates.

You don't have to submit Jipher for testing to a CSTL nor do you need to acquire a CMVP certificate.

Note:

FIPS 140-3 is the latest version of this standard, which supersedes the previous version, FIPS 140-2. In September 2026, FIPS 140-2 validation certificates will be placed on the historical list. This means that Federal Agencies should not include them in new systems but can procure them for legacy systems. See FIPS 140-3 Transition Effort and Cryptographic Module Validation Program.

Jipher Artifacts

Jipher is packaged in a .tar.gz file named jipher-20.0-<platform>.tar.gz. The value of <platform> is one of the following, which correspond to each supported platform:

• linux-aarch64
• linux-x64
• macos-aarch64
• windows-x64

This .tar.gz file contains the following:

• The Jipher JAR file, which is named jipher-jce-20.0.jar.
• A .tar.gz file named jipher-native-20.0-<platform>.tar.gz. This archive contains:
  • The Jipher native library, which facilitates loading the OpenSSL cryptography library through the JNI on JDK 17 and 21
  • The OpenSSL cryptography library, which facilitates loading and communicating with the OpenSSL FIPS provider
  • Two OpenSSL FIPS modules:
    • Certified OpenSSL module: 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-3 validation certificate
    • Patched OpenSSL module: A version of the OpenSSL FIPS module built from the FIPS 140-3 compliant baseline source code with additional security patches applied, which is used by default

Independence from and Coexistence with Other Instances of OpenSSL

Jipher’s native runtime dependencies, which include an instance of the OpenSSL cryptography library, are distributed in the jipher-native package and should be installed in the target filesystem. By default, Jipher loads and uses this bundled OpenSSL instance at runtime. Jipher therefore does not rely on the OpenSSL version provided by the operating system or by another installed package.

The OpenSSL cryptography library packaged in jipher-native is built so that references to symbols defined within the library resolve to that library’s own definitions. In addition, Jipher loads the library without exporting its public symbols to the process-wide dynamic-linker namespace.

Together, these measures reduce the risk of symbol interposition when Jipher runs in a process that also loads another OpenSSL instance.