Liking cljdoc? Tell your friends :D

javax.crypto.AEADBadTagException

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 Cipher operating in
an AEAD mode (such as GCM/CCM) is unable to verify the supplied
authentication tag.
raw docstring

javax.crypto.BadPaddingException

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

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

javax.crypto.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. 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.

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.
raw docstring

javax.crypto.CipherInputStream

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 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.
raw docstring

javax.crypto.CipherOutputStream

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.

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.
raw docstring

javax.crypto.CipherSpi

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 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.
raw docstring

javax.crypto.core

No vars found in this namespace.

javax.crypto.EncryptedPrivateKeyInfo

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 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  }
raw docstring

javax.crypto.ExemptionMechanism

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 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.
raw docstring

javax.crypto.ExemptionMechanismException

This is the generic ExemptionMechanism exception.

This is the generic ExemptionMechanism exception.
raw docstring

javax.crypto.ExemptionMechanismSpi

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 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.
raw docstring

javax.crypto.IllegalBlockSizeException

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.

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.
raw docstring

javax.crypto.interfaces.core

No vars found in this namespace.

javax.crypto.interfaces.DHKey

The interface to a Diffie-Hellman key.

The interface to a Diffie-Hellman key.
raw docstring

javax.crypto.interfaces.DHPrivateKey

The interface to a Diffie-Hellman private key.

The interface to a Diffie-Hellman private key.
raw docstring

javax.crypto.interfaces.DHPublicKey

The interface to a Diffie-Hellman public key.

The interface to a Diffie-Hellman public key.
raw docstring

javax.crypto.interfaces.PBEKey

The interface to a PBE key.

The interface to a PBE key.
raw docstring

javax.crypto.KeyAgreement

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 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.
raw docstring

javax.crypto.KeyAgreementSpi

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 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.
raw docstring

javax.crypto.KeyGenerator

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 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.
raw docstring

javax.crypto.KeyGeneratorSpi

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 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.
raw docstring

javax.crypto.Mac

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 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.
raw docstring

javax.crypto.MacSpi

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 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.
raw docstring

javax.crypto.NoSuchPaddingException

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

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

javax.crypto.NullCipher

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.

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.
raw docstring

javax.crypto.SealedObject

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.

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.
raw docstring

javax.crypto.SecretKey

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

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

No vars found in this namespace.

javax.crypto.SecretKeyFactory

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 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.
raw docstring

javax.crypto.SecretKeyFactorySpi

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 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.
raw docstring

javax.crypto.ShortBufferException

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

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

javax.crypto.spec.core

No vars found in this namespace.

javax.crypto.spec.DESedeKeySpec

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

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

javax.crypto.spec.DHGenParameterSpec

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 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.
raw docstring

javax.crypto.spec.DHParameterSpec

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 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.
raw docstring

javax.crypto.spec.DHPrivateKeySpec

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 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.
raw docstring

javax.crypto.spec.DHPublicKeySpec

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.

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.
raw docstring

javax.crypto.spec.GCMParameterSpec

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.

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.
raw docstring

javax.crypto.spec.IvParameterSpec

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 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.
raw docstring

javax.crypto.spec.OAEPParameterSpec

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

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
raw docstring

javax.crypto.spec.PBEKeySpec

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.

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.
raw docstring

javax.crypto.spec.PBEParameterSpec

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

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

javax.crypto.spec.PSource

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 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 --
}
raw docstring

javax.crypto.spec.PSource$PSpecified

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

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

javax.crypto.spec.RC2ParameterSpec

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
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.
raw docstring

javax.crypto.spec.RC5ParameterSpec

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 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.
raw docstring

javax.crypto.spec.SecretKeySpec

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.

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.
raw docstring

cljdoc is a website building & hosting documentation for Clojure/Script libraries

× close