
IBMJCEPlus and IBMJCEPlusFIPS providers
The IBMJCEPlus and IBMJCEPlusFIPS cryptographic providers are implementations of the Java™ Cryptography Extensions (JCE) APIs, which include, for example: ciphers, signatures, message digests, MACs and HMACs, secure random number generation, and key generation.
The IBMJCEPlusFIPS provider provides cryptographic functions to the IBM JSSE2 provider when the latter is used in FIPS mode, which you can enable if you want to use only FIPS-certified cryptography. For more information, see Running IBMJSSE2 in FIPS mode. This separation of function enables improvements and enhancements in IBM JSSE2 without affecting FIPS certification.
The IBMJCEPlus and IBMJCEPlusFIPS providers are supported on AIX®, Windows, and Linux®. From service refresh 6, fix pack 25,
the IBMJCEPlus provider is also supported on z/OS®; the
IBMJCEPlusFIPS provider is not yet supported on that operating system.
The IBMJCEPlus and IBMJCEPlusFIPS cryptographic providers are intended to supercede the IBMJCE and IBMJCEFIPS providers. The newer providers have similar functionality to their older equivalents, although currently the IBMJCEPlus provider does not support key management or use of the keytool utility. The newer providers offer: support for newer algorithms (some of which are required for TLS 1.3), additional hardware-accelerated cryptographic capabilities (where supported), and performance enhancements. IBMJCEPlusFIPS also has later FIPS certification, which will continue to be renewed when needed; the certificate for IBMJCEFIPS will not be renewed nor will new enhancements be added, so you should use the newer providers where possible.
The providers are contained within a single .jar file, ibmjceplus.jar. The IBMJCEPlus provider is not FIPS-compliant, whereas the IBMJCEPlusFIPS provider is (see Certificate #3064).
- RSA decryption with the NoPadding option leaves padding bytes in the decrypted text because it is not known whether some of the 0 bytes are padding bytes or part of the plaintext. This behavior matches the behavior of the Oracle JDK. The IBMJCE and IBMJCEFIPS providers attempt to remove the padding bytes and strip all leading 0 bytes. Leading 0 bytes in the plaintext are therefore removed in the recovered text.
- While in FIPS mode (using IBMJCEPlusFIPS), asymmetric key generation might periodically fail to produce keys of the appropriate size. The underlying implementation might fail with a 1-in-256 chance. If a failure occurs, call the key generation routine again.
Supported algorithms
The following tables show the algorithms that are currently supported. Additional algorithm support is intended for future releases.

- DH
- RSAPSS
- ChaCha20 and ChaCha20-Poly1305 (IBMJCEPlus provider only)
- kda-hkdf-with-sha1, kda-hkdf-with-sha224, kda-hkdf-with-sha256, kda-hkdf-with-shasha384, and kda-hkdf-with-sha512 (IBMJCEPlus provider only)


- XDH (X25519, X448)


- HMAC-SHA3 algorithms for message authentication code (IBMJCEPlus provider only)
- SHA3 algorithms for creating message digests (IBMJCEPlus provider only)


- The AES algorithm now supports the CTR cipher mode of operation.

API | Supported algorithms |
---|---|
Algorithm parameter | AES, ChaCha20, ChaCha20-Poly1305, DESede, DSA, EC, GCM, DH, OAEP, RSAPSS |
Algorithm parameter generator | DH, DSA, EC, GCM |
Cipher algorithms | AES, ChaCha20, ChaCha20-Poly1305, DESede, RSA |
Cipher modes |
AES supports these modes: CFB8, CFB128, CFB, ECB, CBC, OFB, GCM, CTR
DESede supports these modes: ECB, CBC RSA supports these modes: null, ECB, SSL |
Key agreement algorithms | DH, ECDH, XDH (X25519, X448) |
Key factory | DH, DSA, EC, RSA, RSAPSS, XDH (X25519, X448) |
Key generator | AES, ChaCha20, DESede, HmacMD5, HmacSHA1, HmacSHA224, HmacSHA256, HmacSHA384, HmacSHA512, HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, HmacSHA3-512 , kda-hkdf-with-sha1, kda-hkdf-with-sha224, kda-hkdf-with-sha256, kda-hkdf-with-shasha384, kda-hkdf-with-sha512 |
Key pair generator | DH, DSA, EC, RSA, XDH (X25519, X448) |
Message authentication code (MAC) | HmacMD5, HmacSHA1, HmacSHA224, HmacSHA256, HmacSHA384, HmacSHA512, HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, HmacSHA3-512 |
Message digest | MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, HmacSHA3-512 |
Secret key factory | AES, ChaCha20, DESede |
Secure random | HASHDRBG, SHA256DRBG, SHA512DRBG |
Signature algorithms | NONEwithDSA, RSAPSS, SHA1withDSA, SHA224withDSA, SHA256withDSA, NONEwithECDSA, SHA1withECDSA, SHA224withECDSA, SHA256withECDSA, SHA384withECDSA, SHA512withECDSA, NONEwithRSA, SHA1withRSA, SHA224withRSA, SHA256withRSA, SHA384withRSA, SHA512withRSA, SHA3-224withDSA, SHA3-256withDSA, SHA3-384withDSA, SHA3-512withDSA, SHA3-224withECDSA, SHA3-256withECDSA, SHA3-384withECDSA, SHA3-512withECDSA, SHA3-224withRSA, SHA3-256withRSA, SHA3-384withRSA, SHA3-512withRSA |
API | Supported algorithms |
---|---|
Algorithm parameter | AES, DESede, DH, DSA, EC, GCM, OAEP, RSAPSS |
Algorithm parameter generator | DSA, EC, GCM, DH |
Cipher algorithms | AES, DESede, RSA |
Cipher modes |
AES supports these modes: CFB8, CFB128, CFB, ECB, CBC, OFB, GCM, CTR
DESede supports these modes: ECB, CBC RSA supports these modes: null, ECB, SSL |
Key agreement algorithms | DH, ECDH |
Key factory | DH, DSA, EC, RSA, RSAPSS |
Key generator | AES, DESede, HmacMD5, HmacSHA1, HmacSHA224, HmacSHA256, HmacSHA384, HmacSHA512 |
Key pair generator | DH, DSA, EC, RSA |
Message authentication code (MAC) | HmacMD5, HmacSHA1, HmacSHA224, HmacSHA256, HmacSHA384, HmacSHA512 |
Message digest | MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 |
Secret key factory | AES, DESede |
Secure random | HASHDRBG, SHA256DRBG, SHA512DRBG |
Signature algorithms | NONEwithDSA, RSAPSS, SHA1withDSA, SHA224withDSA, SHA256withDSA, NONEwithECDSA, SHA1withECDSA, SHA224withECDSA, SHA256withECDSA, SHA384withECDSA, SHA512withECDSA, NONEwithRSA, SHA1withRSA, SHA224withRSA, SHA256withRSA, SHA384withRSA, SHA512withRSA |
Supported elliptic curves
secp256r1, 1.2.840.10045.3.1.7, NIST P-256
, and X9.62
prime256v1
refer to the same curve. You can use the curve names to create parameter
specifications for EC parameter generation with the ECGenParameterSpec class.
Curve name | Object identifier | Additional names or aliases |
---|---|---|
secp160k1 |
1.3.132.0.9 |
|
secp160r1 |
1.3.132.0.8 |
|
secp160r2 |
1.3.132.0.30 |
|
secp192k1 |
1.3.132.0.31 |
|
secp192r1 |
1.2.840.10045.3.1.1 |
NIST P-192, X9.62 prime192v1 |
secp224k1 |
1.3.132.0.32 |
|
secp224r1 |
1.3.132.0.33 |
NIST P-224 |
secp256k1 |
1.3.132.0.10 |
|
secp256r1 |
1.2.840.10045.3.1.7 |
NIST P-256, X9.62 prime256v1 |
secp384r1 |
1.3.132.0.34 |
NIST P-384 |
secp521r1 |
1.3.132.0.35 |
NIST P-521 |
X9.62 prime192v2 |
1.2.840.10045.3.1.2 |
|
X9.62 prime192v3 |
1.2.840.10045.3.1.3 |
|
X9.62 prime239v1 |
1.2.840.10045.3.1.4 |
|
X9.62 prime239v2 |
1.2.840.10045.3.1.5 |
|
X9.62 prime239v3 |
1.2.840.10045.3.1.6 |
Curve name | Object identifier |
---|---|
secp112r1 |
1.3.132.0.6 |
secp112r2 |
1.3.132.0.7 |
secp128r1 |
1.3.132.0.28 |
secp128r2 |
1.3.132.0.29 |
Known limitations
- Elliptic Curve Diffie-Hellman Key Agreement is supported. Diffie-Hellman Key Agreement is supported only from service refresh 6.
- RSA private keys must be CRT (Chinese Remainder Theorem) keys. Private keys without the CRT parameters are not supported. Generated key pairs will have CRT private keys.
- RSA decryption with the NoPadding option might leave padding bytes in the decrypted text.
- Binary Elliptic Curves are not supported.
- IBMJCEPlusFIPS asymmetric key generation might periodically fail to produce keys of the appropriate size (1 in 256 chance). If this situation occurs, call the key generation routine again.
- The providers in IBMJCEPlus do not have their own Keystore implementations. Instead, Keystore implementations (JKS, JCEKS, PKCS#12) come from the IBMJCE provider.
The RSA-PSS signature object cannot be initialized with a message digest algorithm that is not the same as the one supplied in the MGFParameterSpec.
Before service refresh 7, the IBMJCEPlus and IBMJCEPlusFIPS providers did not support Cipher.update encryption and decryption operations for the AES-GCM algorithm (see Encrypting and Decrypting Data). From service refresh 7, this restriction is removed.
AES-GCM encryption and decryption Cipher.update operations should be done only for large amounts of data that need to be protected, for the following reason. The authentication tag can be validated only on the doFinal (Cipher.doFinal()) operation; if the doFinal operation fails for any reason, all plaintext that is returned from a previous update operation must be discarded. For smaller amounts of data, it is therefore sensible to run only doFinal operations.
AES-GCM is not suggested for use with the cipher stream APIs (CipherInputStream and CipherOutputStream) because these APIs were not designed to deal with the complexities of AES-GCM, such as the one just described.
