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, 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.

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.

Jipher is packaged in a .tar.gz file named jipher-10.35.tar.gz. It contains the Jipher JAR file, which is named jipher-jce-10.35-se.jar.

This JAR file includes the following:

• A single instance of the Jipher provider classes
• For each supported platform:
  • The Jipher native library, which provides access to OpenSSL functionality through the JNI
  • Two OpenSSL FIPS modules:
    • 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
  • An OpenSSL configuration file

Jipher explicitly loads the OpenSSL native code libraries embedded in the jipher-jce-10.35-se.jar JAR file. Jipher is therefore independent of any other instance of OpenSSL present on the system, including any instance that is part of the operating system distribution. The embedded libraries do not export any symbols from the OpenSSL library, so there will be no symbol clashes in a process that uses Jipher and also loads another instance of OpenSSL.