This exception is thrown when a Cipher operating in
an AEAD mode (such as GCM/CCM) is unable to verify the supplied
authentication tag.

This exception is thrown when a particular padding mechanism is
expected for the input data but the data is not padded properly.

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

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

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.
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 AEAD 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 has 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);
    ...
Every implementation of the Java platform is required to support
the following standard Cipher transformations with the keysizes
in parentheses:

AES/CBC/NoPadding (128)
AES/CBC/PKCS5Padding (128)
AES/ECB/NoPadding (128)
AES/ECB/PKCS5Padding (128)
DES/CBC/NoPadding (56)
DES/CBC/PKCS5Padding (56)
DES/ECB/NoPadding (56)
DES/ECB/PKCS5Padding (56)
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 Cryptography Architecture Standard Algorithm Name Documentation.
Consult the release documentation for your implementation to see if any
other transformations are supported.

A CipherInputStream is composed of an InputStream and a Cipher so
that read() methods return data that are read in from the
underlying InputStream but have been additionally processed by the
Cipher.  The Cipher must be fully initialized before being used by
a CipherInputStream.

 For example, if the Cipher is initialized for decryption, the
CipherInputStream will attempt to read in data and decrypt them,
before returning the decrypted data.

 This class adheres strictly to the semantics, especially the
failure semantics, of its ancestor classes
java.io.FilterInputStream and java.io.InputStream.  This class has
exactly those methods specified in its ancestor classes, and
overrides them all.  Moreover, this class catches all exceptions
that are not thrown by its ancestor classes.  In particular, the
skip method skips, and the available
method counts only data that have been processed by the encapsulated Cipher.
This class may catch BadPaddingException and other exceptions thrown by
failed integrity checks during decryption. These exceptions are not
re-thrown, so the client may not be informed that integrity checks
failed. Because of this behavior, this class may not be suitable
for use with decryption in an authenticated mode of operation (e.g. GCM).
Applications that require authenticated encryption can use the Cipher API
directly as an alternative to using this class.

 It is crucial for a programmer using this class not to use
methods that are not defined or overriden in this class (such as a
new method or constructor that is later added to one of the super
classes), because the design and implementation of those methods
are unlikely to have considered security impact with regard to
CipherInputStream.

A CipherOutputStream is composed of an OutputStream and a Cipher so
that write() methods first process the data before writing them out
to the underlying OutputStream.  The cipher must be fully
initialized before being used by a CipherOutputStream.

 For example, if the cipher is initialized for encryption, the
CipherOutputStream will attempt to encrypt data before writing out the
encrypted data.

 This class adheres strictly to the semantics, especially the
failure semantics, of its ancestor classes
java.io.OutputStream and java.io.FilterOutputStream.  This class
has exactly those methods specified in its ancestor classes, and
overrides them all.  Moreover, this class catches all exceptions
that are not thrown by its ancestor classes. In particular, this
class catches BadPaddingException and other exceptions thrown by
failed integrity checks during decryption. These exceptions are not
re-thrown, so the client will not be informed that integrity checks
failed. Because of this behavior, this class may not be suitable
for use with decryption in an authenticated mode of operation (e.g. GCM)
if the application requires explicit notification when authentication
fails. Such an application can use the Cipher API directly as an
alternative to using this class.

 It is crucial for a programmer using this class not to use
methods that are not defined or overriden in this class (such as a
new method or constructor that is later added to one of the super
classes), because the design and implementation of those methods
are unlikely to have considered security impact with regard to
CipherOutputStream.

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

// provider's subclass of `CipherSpi` implements `algName` with
// pluggable mode and padding
Cipher.algName




// provider's subclass of `CipherSpi` implements `algName` in the
// specified `mode`, with pluggable padding
Cipher.algName/mode




// provider's subclass of `CipherSpi` implements `algName` with the
// specified `padding`, with pluggable mode
Cipher.algName//padding




// provider's subclass of `CipherSpi` implements `algName` with the
// specified `mode` and `padding`
Cipher.algName/mode/padding

Cipher.AES/ECB/PKCS5Padding




Cipher.AES/CBC/PKCS5Padding




Cipher.AES/CFB/PKCS5Padding




Cipher.AES/OFB/PKCS5Padding

Cipher.AES

This class defines the Service Provider Interface (SPI)
for the Cipher class.
All the abstract methods in this class must be implemented by each
cryptographic service provider who wishes to supply the implementation
of a particular cipher algorithm.

In order to create an instance of Cipher, which
encapsulates an instance of this CipherSpi class, an
application calls one of the
getInstance
factory methods of the
Cipher engine class and specifies the requested
transformation.
Optionally, the application may also specify the name of a provider.

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`);

A provider may supply a separate class for each combination
of algorithm/mode/padding, or may decide to provide more generic
classes representing sub-transformations corresponding to
algorithm or algorithm/mode or algorithm//padding
(note the double slashes),
in which case the requested mode and/or padding are set automatically by
the getInstance methods of Cipher, which invoke
the engineSetMode and
engineSetPadding
methods of the provider's subclass of CipherSpi.

A Cipher property in a provider master class may have one of
the following formats:






    // provider's subclass of `CipherSpi` implements `algName` with
    // pluggable mode and padding
    Cipher.algName




    // provider's subclass of `CipherSpi` implements `algName` in the
    // specified `mode`, with pluggable padding
    Cipher.algName/mode




    // provider's subclass of `CipherSpi` implements `algName` with the
    // specified `padding`, with pluggable mode
    Cipher.algName//padding




    // provider's subclass of `CipherSpi` implements `algName` with the
    // specified `mode` and `padding`
    Cipher.algName/mode/padding



For example, a provider may supply a subclass of CipherSpi
that implements AES/ECB/PKCS5Padding, one that implements
AES/CBC/PKCS5Padding, one that implements
AES/CFB/PKCS5Padding, and yet another one that implements
AES/OFB/PKCS5Padding. That provider would have the following
Cipher properties in its master class:






    Cipher.AES/ECB/PKCS5Padding




    Cipher.AES/CBC/PKCS5Padding




    Cipher.AES/CFB/PKCS5Padding




    Cipher.AES/OFB/PKCS5Padding



Another provider may implement a class for each of the above modes
(i.e., one class for ECB, one for CBC, one for CFB,
and one for OFB), one class for PKCS5Padding,
and a generic AES class that subclasses from CipherSpi.
That provider would have the following
Cipher properties in its master class:






    Cipher.AES



The getInstance factory method of the Cipher
engine class follows these rules in order to instantiate a provider's
implementation of CipherSpi for a
transformation of the form `algorithm`:



Check if the provider has registered a subclass of CipherSpi
for the specified `algorithm`.
If the answer is YES, instantiate this
class, for whose mode and padding scheme default values (as supplied by
the provider) are used.
If the answer is NO, throw a NoSuchAlgorithmException
exception.


The getInstance factory method of the Cipher
engine class follows these rules in order to instantiate a provider's
implementation of CipherSpi for a
transformation of the form `algorithm/mode/padding`:



Check if the provider has registered a subclass of CipherSpi
for the specified `algorithm/mode/padding` transformation.
If the answer is YES, instantiate it.
If the answer is NO, go to the next step.

Check if the provider has registered a subclass of CipherSpi
for the sub-transformation `algorithm/mode`.
If the answer is YES, instantiate it, and call
engineSetPadding(padding) on the new instance.
If the answer is NO, go to the next step.

Check if the provider has registered a subclass of CipherSpi
for the sub-transformation `algorithm//padding` (note the double
slashes).
If the answer is YES, instantiate it, and call
engineSetMode(mode) on the new instance.
If the answer is NO, go to the next step.

Check if the provider has registered a subclass of CipherSpi
for the sub-transformation `algorithm`.
If the answer is YES, instantiate it, and call
engineSetMode(mode) and
engineSetPadding(padding) on the new instance.
If the answer is NO, throw a NoSuchAlgorithmException
exception.

This class implements the EncryptedPrivateKeyInfo type
as defined in PKCS #8.
Its ASN.1 definition is as follows:



EncryptedPrivateKeyInfo ::=  SEQUENCE {
    encryptionAlgorithm   AlgorithmIdentifier,
    encryptedData   OCTET STRING }

AlgorithmIdentifier  ::=  SEQUENCE  {
    algorithm              OBJECT IDENTIFIER,
    parameters             ANY DEFINED BY algorithm OPTIONAL  }

This class provides the functionality of an exemption mechanism, examples
of which are key recovery, key weakening, and
key escrow.

Applications or applets that use an exemption mechanism may be granted
stronger encryption capabilities than those which don't.

This is the generic ExemptionMechanism exception.

This class defines the Service Provider Interface (SPI)
for the ExemptionMechanism class.
All the abstract methods in this class must be implemented by each
cryptographic service provider who wishes to supply the implementation
of a particular exemption mechanism.

This exception is thrown when the length of data provided to a block
cipher is incorrect, i.e., does not match the block size of the cipher.

The interface to a Diffie-Hellman key.

The interface to a Diffie-Hellman private key.

The interface to a Diffie-Hellman public key.

The interface to a PBE key.

This class provides the functionality of a key agreement (or key
exchange) protocol.

The keys involved in establishing a shared secret are created by one of the
key generators (KeyPairGenerator or
KeyGenerator), a KeyFactory, or as a result from
an intermediate phase of the key agreement protocol.

 For each of the correspondents in the key exchange, doPhase
needs to be called. For example, if this key exchange is with one other
party, doPhase needs to be called once, with the
lastPhase flag set to true.
If this key exchange is
with two other parties, doPhase needs to be called twice,
the first time setting the lastPhase flag to
false, and the second time setting it to true.
There may be any number of parties involved in a key exchange.

 Every implementation of the Java platform is required to support the
following standard KeyAgreement algorithm:

DiffieHellman

This algorithm is described in the
KeyAgreement section of the
Java Cryptography Architecture Standard Algorithm Name Documentation.
Consult the release documentation for your implementation to see if any
other algorithms are supported.

This class defines the Service Provider Interface (SPI)
for the KeyAgreement class.
All the abstract methods in this class must be implemented by each
cryptographic service provider who wishes to supply the implementation
of a particular key agreement algorithm.

 The keys involved in establishing a shared secret are created by one
of the
key generators (KeyPairGenerator or
KeyGenerator), a KeyFactory, or as a result from
an intermediate phase of the key agreement protocol
(engineDoPhase).

 For each of the correspondents in the key exchange,
engineDoPhase
needs to be called. For example, if the key exchange is with one other
party, engineDoPhase needs to be called once, with the
lastPhase flag set to true.
If the key exchange is
with two other parties, engineDoPhase needs to be called twice,
the first time setting the lastPhase flag to
false, and the second time setting it to true.
There may be any number of parties involved in a key exchange.

This class provides the functionality of a secret (symmetric) key generator.

Key generators are constructed using one of the getInstance
class methods of this class.

KeyGenerator objects are reusable, i.e., after a key has been
generated, the same KeyGenerator object can be re-used to generate further
keys.

There are two ways to generate a key: in an algorithm-independent
manner, and in an algorithm-specific manner.
The only difference between the two is the initialization of the object:


Algorithm-Independent Initialization
All key generators share the concepts of a keysize and a
source of randomness.
There is an
init
method in this KeyGenerator class that takes these two universally
shared types of arguments. There is also one that takes just a
keysize argument, and uses the SecureRandom implementation
of the highest-priority installed provider as the source of randomness
(or a system-provided source of randomness if none of the installed
providers supply a SecureRandom implementation), and one that takes just a
source of randomness.

Since no other parameters are specified when you call the above
algorithm-independent init methods, it is up to the
provider what to do about the algorithm-specific parameters (if any) to be
associated with each of the keys.

Algorithm-Specific Initialization
For situations where a set of algorithm-specific parameters already
exists, there are two
init
methods that have an AlgorithmParameterSpec
argument. One also has a SecureRandom argument, while the
other uses the SecureRandom implementation
of the highest-priority installed provider as the source of randomness
(or a system-provided source of randomness if none of the installed
providers supply a SecureRandom implementation).


In case the client does not explicitly initialize the KeyGenerator
(via a call to an init method), each provider must
supply (and document) a default initialization.

 Every implementation of the Java platform is required to support the
following standard KeyGenerator algorithms with the keysizes in
parentheses:

AES (128)
DES (56)
DESede (168)
HmacSHA1
HmacSHA256

These algorithms are described in the
KeyGenerator section of the
Java Cryptography Architecture Standard Algorithm Name Documentation.
Consult the release documentation for your implementation to see if any
other algorithms are supported.

This class defines the Service Provider Interface (SPI)
for the KeyGenerator class.
All the abstract methods in this class must be implemented by each
cryptographic service provider who wishes to supply the implementation
of a key generator for a particular algorithm.

This class provides the functionality of a `Message Authentication Code`
(MAC) algorithm.

 A MAC provides a way to check
the integrity of information transmitted over or stored in an unreliable
medium, based on a secret key. Typically, message
authentication codes are used between two parties that share a secret
key in order to validate information transmitted between these
parties.

 A MAC mechanism that is based on cryptographic hash functions is
referred to as HMAC. HMAC can be used with any cryptographic hash function,
e.g., SHA256 or SHA384, in combination with a secret shared key. HMAC is
specified in RFC 2104.

 Every implementation of the Java platform is required to support
the following standard Mac algorithms:

HmacMD5
HmacSHA1
HmacSHA256

These algorithms are described in the

Mac section of the
Java Cryptography Architecture Standard Algorithm Name Documentation.
Consult the release documentation for your implementation to see if any
other algorithms are supported.

This class defines the Service Provider Interface (SPI)
for the Mac class.
All the abstract methods in this class must be implemented by each
cryptographic service provider who wishes to supply the implementation
of a particular MAC algorithm.

 Implementations are free to implement the Cloneable interface.

This exception is thrown when a particular padding mechanism is
requested but is not available in the environment.

The NullCipher class is a class that provides an
`identity cipher` -- one that does not transform the plain text.  As
a consequence, the ciphertext is identical to the plaintext.  All
initialization methods do nothing, while the blocksize is set to 1
byte.

This class enables a programmer to create an object and protect its
confidentiality with a cryptographic algorithm.

 Given any Serializable object, one can create a SealedObject
that encapsulates the original object, in serialized
format (i.e., a `deep copy`), and seals (encrypts) its serialized contents,
using a cryptographic algorithm such as AES, to protect its
confidentiality.  The encrypted content can later be decrypted (with
the corresponding algorithm using the correct decryption key) and
de-serialized, yielding the original object.

 Note that the Cipher object must be fully initialized with the
correct algorithm, key, padding scheme, etc., before being applied
to a SealedObject.

 The original object that was sealed can be recovered in two different
ways:



by using the getObject
method that takes a Cipher object.

 This method requires a fully initialized Cipher object,
initialized with the
exact same algorithm, key, padding scheme, etc., that were used to seal the
object.

 This approach has the advantage that the party who unseals the
sealed object does not require knowledge of the decryption key. For example,
after one party has initialized the cipher object with the required
decryption key, it could hand over the cipher object to
another party who then unseals the sealed object.

by using one of the
getObject methods
that take a Key object.

 In this approach, the getObject method creates a cipher
object for the appropriate decryption algorithm and initializes it with the
given decryption key and the algorithm parameters (if any) that were stored
in the sealed object.

 This approach has the advantage that the party who
unseals the object does not need to keep track of the parameters (e.g., an
IV) that were used to seal the object.

A secret (symmetric) key.
The purpose of this interface is to group (and provide type safety
for) all secret key interfaces.

Provider implementations of this interface must overwrite the
equals and hashCode methods inherited from
Object, so that secret keys are compared based on
their underlying key material and not based on reference.
Implementations should override the default destroy and
isDestroyed methods from the
Destroyable interface to enable
sensitive key information to be destroyed, cleared, or in the case
where such information is immutable, unreferenced.
Finally, since SecretKey is Serializable, implementations
should also override
ObjectOutputStream.writeObject(java.lang.Object)
to prevent keys that have been destroyed from being serialized.

Keys that implement this interface return the string RAW
as their encoding format (see getFormat), and return the
raw key bytes as the result of a getEncoded method call. (The
getFormat and getEncoded methods are inherited
from the Key parent interface.)

This class represents a factory for secret keys.

 Key factories are used to convert keys (opaque
cryptographic keys of type Key) into key specifications
(transparent representations of the underlying key material), and vice
versa.
Secret key factories operate only on secret (symmetric) keys.

 Key factories are bi-directional, i.e., they allow to build an opaque
key object from a given key specification (key material), or to retrieve
the underlying key material of a key object in a suitable format.

 Application developers should refer to their provider's documentation
to find out which key specifications are supported by the
generateSecret and
getKeySpec
methods.
For example, the DES secret-key factory supplied by the `SunJCE` provider
supports DESKeySpec as a transparent representation of DES
keys, and that provider's secret-key factory for Triple DES keys supports
DESedeKeySpec as a transparent representation of Triple DES
keys.

 Every implementation of the Java platform is required to support the
following standard SecretKeyFactory algorithms:

DES
DESede

These algorithms are described in the
SecretKeyFactory section of the
Java Cryptography Architecture Standard Algorithm Name Documentation.
Consult the release documentation for your implementation to see if any
other algorithms are supported.

This class defines the Service Provider Interface (SPI)
for the SecretKeyFactory class.
All the abstract methods in this class must be implemented by each
cryptographic service provider who wishes to supply the implementation
of a secret-key factory for a particular algorithm.

 A provider should document all the key specifications supported by its
secret key factory.
For example, the DES secret-key factory supplied by the `SunJCE` provider
supports DESKeySpec as a transparent representation of DES
keys, and that provider's secret-key factory for Triple DES keys supports
DESedeKeySpec as a transparent representation of Triple DES
keys.

This exception is thrown when an output buffer provided by the user
is too short to hold the operation result.

This class specifies a DES-EDE (`triple-DES`) key.

This class specifies a DES key.

This class specifies the set of parameters used for generating
Diffie-Hellman (system) parameters for use in Diffie-Hellman key
agreement. This is typically done by a central
authority.

 The central authority, after computing the parameters, must send this
information to the parties looking to agree on a secret key.

This class specifies the set of parameters used with the Diffie-Hellman
algorithm, as specified in PKCS #3: Diffie-Hellman Key-Agreement
Standard.

A central authority generates parameters and gives them to the two
entities seeking to generate a secret key. The parameters are a prime
p, a base g, and optionally the length
in bits of the private value, l.

It is possible that more than one instance of parameters may be
generated by a given central authority, and that there may be more than
one central authority. Indeed, each individual may be its own central
authority, with different entities having different parameters.

Note that this class does not perform any validation on specified
parameters. Thus, the specified values are returned directly even
if they are null.

This class specifies a Diffie-Hellman private key with its associated
parameters.

Note that this class does not perform any validation on specified
parameters. Thus, the specified values are returned directly even
if they are null.

This class specifies a Diffie-Hellman public key with its associated
parameters.

Note that this class does not perform any validation on specified
parameters. Thus, the specified values are returned directly even
if they are null.

Specifies the set of parameters required by a Cipher using the Galois/Counter Mode (GCM) mode.

Simple block cipher modes (such as CBC) generally require only an
initialization vector (such as IvParameterSpec),
but GCM needs these parameters:

IV: Initialization Vector (IV)
tLen: length (in bits) of authentication tag T


In addition to the parameters described here, other GCM inputs/output
(Additional Authenticated Data (AAD), Keys, block ciphers,
plain/ciphertext and authentication tags) are handled in the Cipher class.

Please see  RFC 5116
 for more information on the Authenticated Encryption with
Associated Data (AEAD) algorithm, and
NIST Special Publication 800-38D, `NIST Recommendation for Block
Cipher Modes of Operation:  Galois/Counter Mode (GCM) and GMAC.`

The GCM specification states that tLen may only have the
values {128, 120, 112, 104, 96}, or {64, 32} for certain
applications.  Other values can be specified for this class, but not
all CSP implementations will support them.

This class specifies an initialization vector (IV).
Examples which use IVs are ciphers in feedback mode,
e.g., DES in CBC mode and RSA ciphers with OAEP encoding
operation.

This class specifies the set of parameters used with OAEP Padding,
as defined in the
PKCS #1
standard.

Its ASN.1 definition in PKCS#1 standard is described below:


RSAES-OAEP-params ::= SEQUENCE {
  hashAlgorithm      [0] OAEP-PSSDigestAlgorithms     DEFAULT sha1,
  maskGenAlgorithm   [1] PKCS1MGFAlgorithms  DEFAULT mgf1SHA1,
  pSourceAlgorithm   [2] PKCS1PSourceAlgorithms  DEFAULT pSpecifiedEmpty
}
where


OAEP-PSSDigestAlgorithms    ALGORITHM-IDENTIFIER ::= {
  { OID id-sha1 PARAMETERS NULL   }|
  { OID id-sha256 PARAMETERS NULL }|
  { OID id-sha384 PARAMETERS NULL }|
  { OID id-sha512 PARAMETERS NULL },
  ...  -- Allows for future expansion --
}
PKCS1MGFAlgorithms    ALGORITHM-IDENTIFIER ::= {
  { OID id-mgf1 PARAMETERS OAEP-PSSDigestAlgorithms },
  ...  -- Allows for future expansion --
}
PKCS1PSourceAlgorithms    ALGORITHM-IDENTIFIER ::= {
  { OID id-pSpecified PARAMETERS OCTET STRING },
  ...  -- Allows for future expansion --
}
Note: the OAEPParameterSpec.DEFAULT uses the following:
    message digest  -- `SHA-1`
    mask generation function (mgf) -- `MGF1`
    parameters for mgf -- MGF1ParameterSpec.SHA1
    source of encoding input -- PSource.PSpecified.DEFAULT

A user-chosen password that can be used with password-based encryption
(PBE).

The password can be viewed as some kind of raw key material, from which
the encryption mechanism that uses it derives a cryptographic key.

Different PBE mechanisms may consume different bits of each password
character. For example, the PBE mechanism defined in

PKCS #5 looks at only the low order 8 bits of each character, whereas
PKCS #12 looks at all 16 bits of each character.

You convert the password characters to a PBE key by creating an
instance of the appropriate secret-key factory. For example, a secret-key
factory for PKCS #5 will construct a PBE key from only the low order 8 bits
of each password character, whereas a secret-key factory for PKCS #12 will
take all 16 bits of each character.

Also note that this class stores passwords as char arrays instead of
String objects (which would seem more logical), because the
String class is immutable and there is no way to overwrite its
internal value when the password stored in it is no longer needed. Hence,
this class requests the password as a char array, so it can be overwritten
when done.

This class specifies the set of parameters used with password-based
encryption (PBE), as defined in the
PKCS #5
standard.

This class specifies the source for encoding input P in OAEP Padding,
as defined in the
PKCS #1
standard.


PKCS1PSourceAlgorithms    ALGORITHM-IDENTIFIER ::= {
  { OID id-pSpecified PARAMETERS OCTET STRING },
  ...  -- Allows for future expansion --
}

This class is used to explicitly specify the value for
encoding input P in OAEP Padding.

This class specifies the parameters used with the
RC2
algorithm.

 The parameters consist of an effective key size and optionally
an 8-byte initialization vector (IV) (only in feedback mode).

 This class can be used to initialize a Cipher object that
implements the RC2 algorithm.

This class specifies the parameters used with the
RC5
algorithm.

 The parameters consist of a version number, a rounds count, a word
size, and optionally an initialization vector (IV) (only in feedback mode).

 This class can be used to initialize a Cipher object that
implements the RC5 algorithm as supplied by
RSA Security Inc.,
or any parties authorized by RSA Security.

This class specifies a secret key in a provider-independent fashion.

It can be used to construct a SecretKey from a byte array,
without having to go through a (provider-based)
SecretKeyFactory.

This class is only useful for raw secret keys that can be represented as
a byte array and have no key parameters associated with them, e.g., DES or
Triple DES keys.