Class Cipher

This class provides the functionality of a cryptographic cipher for encryption and decryption. It forms the core of the Java Cryptographic Extension (JCE) framework.

In order to create a Cipher object, the application calls the cipher's getInstance method, and passes the name of the requested transformation to it. Optionally, the name of a provider may be specified.

A transformation is a string that describes the operation (or set of operations) to be performed on the given input, to produce some output. A transformation always includes the name of a cryptographic algorithm (e.g., AES), and may be followed by a feedback mode and padding scheme.

A transformation is of the form:

• "algorithm/mode/padding" or
• "algorithm"

(in the latter case, provider-specific default values for the mode and padding scheme are used). For example, the following is a valid transformation:

     Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding");
 

Using modes such as CFB and OFB , block ciphers can encrypt data in units smaller than the cipher's actual block size. When requesting such a mode, you may optionally specify the number of bits to be processed at a time by appending this number to the mode name as shown in the "AES/CFB8/NoPadding " and "AES/OFB32/PKCS5Padding " transformations. If no such number is specified, a provider-specific default is used. (See the Moved out of a link with destination https://docs.oracle.com/pls/topic/lookup?ctx=javase20&id=security_guide_jdk_providers.Moved to a link with destination https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=security_guide_jdk_providers.JDK Providers DocumentationMoved out of a link with destination https://docs.oracle.com/pls/topic/lookup?ctx=javase20&id=security_guide_jdk_providers.Moved to a link with destination https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=security_guide_jdk_providers. for the JDK Providers default values.) Thus, block ciphers can be turned into byte-oriented stream ciphers by using an 8 bit mode such as CFB8 or OFB8.

Modes such as Authenticated Encryption with Associated Data (AEAD) provide authenticity assurances for both confidential data and Additional Associated Data (AAD) that is not encrypted. (Please see RFC 5116 for more information on AEAD and AAD algorithms such as GCM/CCM.) Both confidential and AAD data can be used when calculating the authentication tag (similar to a Mac ). This tag is appended to the ciphertext during encryption, and is verified on decryption.

AEAD modes such as GCM/CCM perform all AAD authenticity calculations before starting the ciphertext authenticity calculations. To avoid implementations having to internally buffer ciphertext, all AAD data must be supplied to GCM/CCM implementations (via the updateAAD methods) before the ciphertext is processed (via the update and doFinal methods).

Note that GCM mode has a uniqueness requirement on IVs used in encryption with a given key. When IVs are repeated for GCM encryption, such usages are subject to forgery attacks. Thus, after each encryption operation using GCM mode, callers should re-initialize the Cipher objects with GCM parameters which have a different IV value.

     GCMParameterSpec s = ...;
     cipher.init(..., s);

     // If the GCM parameters were generated by the provider, it can
     // be retrieved by:
     // cipher.getParameters().getParameterSpec(GCMParameterSpec.class);

     cipher.updateAAD(...);  // AAD
     cipher.update(...);     // Multi-part update
     cipher.doFinal(...);    // conclusion of operation

     // Use a different IV value for every encryption
     byte[] newIv = ...;
     s = new GCMParameterSpec(s.getTLen(), newIv);
     cipher.init(..., s);
     ...

 

The ChaCha20 and ChaCha20-Poly1305 algorithms have a similar requirement for unique nonces with a given key. After each encryption or decryption operation, callers should re-initialize their ChaCha20 or ChaCha20-Poly1305 ciphers with parameters that specify a different nonce value. Please see RFC 7539 for more information on the ChaCha20 and ChaCha20-Poly1305 algorithms.

Every implementation of the Java platform is required to support the following standard Cipher object transformations with the keysizes in parentheses:

• AES/CBC/NoPadding (128)
• AES/CBC/PKCS5Padding (128)
• AES/ECB/NoPadding (128)
• AES/ECB/PKCS5Padding (128)
• AES/GCM/NoPadding (128)
• DESede/CBC/NoPadding (168)
• DESede/CBC/PKCS5Padding (168)
• DESede/ECB/NoPadding (168)
• DESede/ECB/PKCS5Padding (168)
• RSA/ECB/PKCS1Padding (1024, 2048)
• RSA/ECB/OAEPWithSHA-1AndMGF1Padding (1024, 2048)
• RSA/ECB/OAEPWithSHA-256AndMGF1Padding (1024, 2048)

These transformations are described in the Cipher section of the Java Security Standard Algorithm Names Specification. Consult the release documentation for your implementation to see if any other transformations are supported.