Start of changes for service refresh 5 fix pack 10

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®. Start of changes for service refresh 6 fix pack 25From 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.End of changes for service refresh 6 fix pack 25

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

Both providers use native interfaces to various hardware platforms, offering hardware-accelerated cryptographic algorithms where supported, which is an advantage over the standard IBMJCE and IBMJCEFIPS providers. Although the IBMJCEPlus and IBMJCEPlusFIPS providers have similar functionality to the IBMJCE and IBMJCEFIPS providers, the "Plus" providers can operate differently in some situations. The following list shows known differences in behavior:
  • 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.

Start of changes for service refresh 6Support for the following algorithms was added in service refresh 6:
  • 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)
End of changes for service refresh 6
Start of changes for service refresh 6 fix pack 10Support for the following algorithms was added in service refresh 6, fix pack 10:
  • XDH (X25519, X448)
End of changes for service refresh 6 fix pack 10
Start of changes for service refresh 7Support for the following algorithms was added in service refresh 7:
  • HMAC-SHA3 algorithms for message authentication code (IBMJCEPlus provider only)
  • SHA3 algorithms for creating message digests (IBMJCEPlus provider only)
End of changes for service refresh 7
Start of changes for service refresh 7 fix pack 5Support for the following algorithms was updated in service refresh 7 fix pack 5:
  • The AES algorithm now supports the CTR cipher mode of operation.
End of changes for service refresh 7 fix pack 5
Table 1. Algorithms supported by the IBMJCEPlus provider
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
Table 2. Algorithms supported by the IBMJCEPlusFIPS provider
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

The following table lists the elliptic curves that the IBMJCEPlus and IBMJCEPlusFIPS providers implement, their object identifier, and any additional names or aliases that are used to refer to them. All the strings that appear in one row refer to the same curve. For example, the strings 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.
Table 3. Elliptic curves implemented by IBMJCEPlus and IBMJCEPlusFIPS
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  
The following table lists other elliptic curves that are implemented by the IBMJCEPlus provider only.
Table 4. Elliptic curves implemented by the IBMJCEPlus provider only
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.
  • Start of changes for service refresh 6The RSA-PSS signature object cannot be initialized with a message digest algorithm that is not the same as the one supplied in the MGFParameterSpec.End of changes for service refresh 6
  • Start of changes for service refresh 7Before 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.

    End of changes for service refresh 7
These limitations also affect the IBMJSSE2 provider, if you use it with the IBMJCEPlus or IBMJCEPlusFIPS provider.
End of changes for service refresh 5 fix pack 10