The JDK Security API requires and uses a set of standard names
for algorithms, certificate and keystore types. This specification
establishes the following names as standard names.
In some cases naming conventions are given for forming names that
are not explicitly listed, to facilitate name consistency across
provider implementations. Items in angle brackets (such as
<digest> and <encryption>) are
placeholders to be replaced by a specific message digest, encryption
algorithm, or other name.
Note: Standard
names are not case-sensitive.
This document includes corresponding lists of standard names
relevant to the following security subareas:
The algorithms in this section can be specified when generating an
instance of CertPathBuilder.
Alg. Name
Description
PKIX
The PKIX certification path validation algorithm as defined in
the ValidationAlgorithm service attribute.
The output of CertPathBuilder instances implementing this
algorithm is a certification path validated against the PKIX
validation algorithm.
The following encodings may be passed to the getEncoded method
of CertPath or the
generateCertPath(InputStream inStream, String encoding) method
of CertificateFactory.
Encoding
Description
PKCS7
A PKCS#7 SignedData object, with the only significant field
being certificates. In particular, the signature and the
contents are ignored. If no certificates are present, a
zero-length CertPath is assumed. Warning: PKCS#7
does not maintain the order of certificates in a certification
path. This means that if a CertPath is converted
to PKCS#7 encoded bytes and then converted back, the order of
the certificates may change, potentially rendering the
CertPath invalid. Users should be aware of this
behavior. See RSA Security
for details on PKCS7.
PkiPath
an ASN.1 DER encoded sequence of certificates, defined as follows:
PkiPath ::= SEQUENCE OF Certificate
Within the sequence, the order of certificates is such that the
subject of the first certificate is the issuer of the second
certificate, etc. Each certificate in PkiPath
shall be unique. No certificate may appear more than once in a
value of Certificate in PkiPath. The
PkiPath format is defined in defect report 279
against X.509 (2000) and is incorporated into Technical
Corrigendum 1 (DTC 2) for the ITU-T Recommendation X.509
(2000). See the
ITU website for details.
The types in this section can be specified when generating an instance
of CertStore.
Type
Description
Collection
A CertStore implementation that retrieves
certificates and CRLs from a Collection. This type
of CertStore is particularly useful in
applications where certificates or CRLs are received in a bag
or some sort of attachment, such as with a signed email message
or in an SSL negotiation.
LDAP
A CertStore implementation that fetches
certificates and CRLs from an LDAP directory using the schema
defined in the LDAPSchema service attribute.
The following names can be specified as the algorithm
component in a transformation when
requesting an instance of Cipher.
Alg. Name
Description
AES
Advanced Encryption Standard as specified by NIST in
FIPS 197. Also known as the Rijndael algorithm by Joan Daemen and
Vincent Rijmen, AES is a 128-bit block cipher supporting keys
of 128, 192, and 256 bits.
AESWrap
The AES key wrapping algorithm as described in
RFC 3394.
ARCFOUR
A stream cipher believed to be fully interoperable with the RC4
cipher developed by Ron Rivest. For more information, see K.
Kaukonen and R. Thayer, "A Stream Cipher Encryption Algorithm
'Arcfour'", Internet Draft (expired),
draft-kaukonen-cipher-arcfour-03.txt.
The Digital Encryption Standard as described in
FIPS PUB 46-3.
DESede
Triple DES Encryption (also known as DES-EDE, 3DES, or
Triple-DES). Data is encrypted using the DES algorithm three
separate times. It is first encrypted using the first subkey, then
decrypted with the second subkey, and encrypted with the third
subkey.
DESedeWrap
The DESede key wrapping algorithm as described in
RFC 3217 .
The password-based encryption algorithm found in (PKCS5), using
the specified message digest (<digest>) or pseudo-random
function (<prf>) and encryption algorithm
(<encryption>). Examples:
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 "DES/CFB8/NoPadding" and
"DES/OFB32/PKCS5Padding" transformations. If no such
number is specified, a provider-specific default is used. (For
example, the SunJCE provider uses a default of 64 bits for
DES.) Thus, block ciphers can be turned into byte-oriented
stream ciphers by using an 8 bit mode such as CFB8 or OFB8.
CTR
A simplification of OFB, Counter mode updates the input block as
a counter.
CTS
Cipher Text Stealing, as described in Bruce Schneier's book
Applied Cryptography-Second Edition, John Wiley and Sons,
1996.
ECB
Electronic Codebook Mode, as defined in FIPS
PUB 81.
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 "DES/CFB8/NoPadding" and
"DES/OFB32/PKCS5Padding" transformations. If no such
number is specified, a provider-specific default is used. (For
example, the SunJCE provider uses a default of 64 bits for
DES.) Thus, block ciphers can be turned into byte-oriented
stream ciphers by using an 8 bit mode such as CFB8 or OFB8.
PCBC
Propagating Cipher Block Chaining, as defined by
Kerberos V4.
Cipher Algorithm Padding
The following names can be specified as the padding
component in a transformation when
requesting an instance of Cipher.
Alg. Name
Description
NoPadding
No padding.
ISO10126Padding
This padding for block ciphers is described in 5.2
Block Encryption Algorithms in the W3C's "XML Encryption
Syntax and Processing" document.
OAEPPadding,
OAEPWith<digest>And<mgf>Padding
Optimal Asymmetric Encryption Padding scheme defined in PKCS1,
where <digest> should be replaced by the message
digest and <mgf> by the mask generation function.
Examples: OAEPWithMD5AndMGF1Padding and
OAEPWithSHA-512AndMGF1Padding.
If OAEPPadding is used, Cipher objects are
initialized with a javax.crypto.spec.OAEPParameterSpec
object to suppply values needed for OAEPPadding.
PKCS1Padding
The padding scheme described in
PKCS1,
used with the RSA algorithm.
The size of an instance of a GenericBlockCipher must be a
multiple of the block cipher's block length.
The padding length, which is always present, contributes to the
padding, which implies that if:
sizeof(content) + sizeof(MAC) % block_length = 0,
padding has to be (block_length - 1) bytes long, because of the
existence of padding_length.
This make the padding scheme similar (but not quite) to
PKCS5Padding, where the padding length is encoded in the
padding (and ranges from 1 to block_length). With the SSL
scheme, the sizeof(padding) is encoded in the always present
padding_length and therefore ranges from 0 to
block_length-1.
The types in this section can be specified when generating an
instance of javax.security.auth.login.Configuration.
Type
Description
JavaLoginConfig
The default Configuration implementation from the SUN provider,
as described in the
ConfigFile class specification.
This type accepts
java.security.URIParameter as a valid
Configuration.Parameter type. If this parameter
is not specified, then the configuration information is loaded
from the sources described in the ConfigFile class
specification. If this parameter is specified, the
configuration information is loaded solely from the specified
URI.
The following exemption mechanism names can be specified in the
permission policy file that accompanies an application considered
"exempt" from cryptographic restrictions:
Alg. Name
Description
KeyEscrow
An encryption system with a backup decryption capability that
allows authorized persons (users, officers of an organization,
and government officials), under certain prescribed conditions,
to decrypt ciphertext with the help of information supplied by
one or more trusted parties who hold special data recovery
keys.
KeyRecovery
A method of obtaining the secret key used to lock encrypted
data. One use is as a means of providing fail-safe access to a
corporation's own encrypted information in times of disaster.
KeyWeakening
A method in which a part of the key can be escrowed or
recovered.
The following mechanisms can be specified when using GSSAPI. Note that
Object Identifiers (OIDs) are specified instead of names to be consistent
with the GSSAPI standard.
Mechanism OID
Description
1.2.840.113554.1.2.2
The Kerberos v5 GSS-API mechanism defined in
RFC 4121.
1.3.6.1.5.5.2
The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
defined in RFC
4178.
Elliptic Curve Diffie-Hellman as defined in ANSI X9.63 and
as described in RFC 3278: "Use
of Elliptic Curve Cryptography (ECC) Algorithms in
Cryptographic Message Syntax (CMS)."
The following algorithm names can be specified when requesting
an instance of Mac.
Alg. Name
Description
HmacMD5
The HMAC-MD5 keyed-hashing algorithm as defined in
RFC 2104
"HMAC: Keyed-Hashing for Message Authentication" (February
1997).
HmacSHA1
HmacSHA256
HmacSHA384
HmacSHA512
The HmacSHA* algorithms as defined in RFC 2104 "HMAC:
Keyed-Hashing for Message Authentication" (February 1997) with
SHA-* as the message digest algorithm.
PBEWith<mac>
Mac for use with the PKCS5 v 2.0
password-based message authentication standard, where
<mac> is a Message Authentication Code algorithm name.
Example: PBEWithHmacSHA1.
SHA-256 is a 256-bit hash function intended to provide 128 bits of
security against collision attacks, while SHA-512 is a 512-bit
hash function intended to provide 256 bits of security.
A 384-bit hash may be obtained by truncating the SHA-512 output.
The types in this section can be specified when generating an
instance of Policy.
Type
Description
JavaPolicy
The default Policy implementation from the SUN provider, as
described in the PolicyFile
guide. This type accepts
java.security.URIParameter as a valid
Policy.Parameter type. If this parameter is not
specified, then the policy information is loaded from the
sources described in the Default Policy File
Locations section of the PolicyFile guide. If this
parameter is specified, the policy information is loaded solely
from the specified URI.
Secret-key factory for use with PKCS5 password-based encryption,
where <digest> is a message digest, <prf> is a
pseudo-random function, and <encryption> is an encryption
algorithm.
Examples:
PBEWithMD5AndDES (PKCS5, v 1.5),
PBEWithHmacSHA1AndDESede (PKCS5, v 2.0), and
Note: These all use only the low order 8 bits of each password
character.
PBKDF2WithHmacSHA1
Constructs secret keys using the Password-Based Key Derivation
Function function found in
PKCS5 v2.0.
The algorithm names in this section can be
specified when generating an instance of SecureRandom.
Alg. Name
Description
SHA1PRNG
The name of the pseudo-random number generation (PRNG)
algorithm supplied by the SUN provider. This algorithm uses
SHA-1 as the foundation of the PRNG. It computes the SHA-1 hash
over a true-random seed value concatenated with a 64-bit
counter which is incremented by 1 for each operation. From the
160-bit SHA-1 output, only 64 bits are used.
A cryptographic service is always associated with a particular
algorithm or type. For example, a digital signature service is
always associated with a particular algorithm (e.g., DSA),
and a CertificateFactory service is always associated with
a particular certificate type (e.g., X.509).
The attributes in this section are for cryptographic services. The
service attributes can be used as filters for selecting providers.
Both the attribute name and value are case insensitive.
Attribute
Description
KeySize
The maximum key size that the provider supports for
the cryptographic service.
ImplementedIn
Whether the implementation for the cryptographic service is
done by software or hardware. The value of this attribute is
"software" or "hardware".
ValidationAlgorithm
The name of the specification that defines the certification path
validation algorithm that an implementation of
CertPathBuilder or CertPathValidator
supports. RFCs should be specified as "RFC#" (ex: "RFC3280") and
Internet Drafts as the name of the draft (ex:
"draft-ietf-pkix-rfc2560bis-01.txt"). Values for this attribute that
are specified as selection criteria to the
Security.getProviders method will be compared using the
String.equalsIgnoreCase method.
All PKIX implementations of CertPathBuilder and
CertPathValidator should provide a value for this
attribute.
LDAPSchema
The name of the specification that defines the LDAP schema that an
implementation of an LDAP CertStore uses to retrieve
certificates and CRLs. The format and semantics of this attribute is
the same as described for the ValidationAlgorithm attribute. All LDAP
implementations of CertStore should provide a value for
this attribute.
The algorithm names in this section can be specified when
generating an instance of Signature.
Alg. Name
Description
NONEwithRSA
The RSA signature algorithm which does not use a digesting
algorithm (e.g. MD5/SHA1) before performing the RSA operation.
For more information about the RSA Signature algorithms, please see
PKCS1.
MD2withRSA
MD5withRSA
The MD2/MD5 with RSA Encryption signature algorithm which uses the
MD2/MD5 digest algorithm and RSA to create and verify RSA digital
signatures as defined in PKCS1.
The signature algorithm with SHA-* and the RSA encryption
algorithm as defined in the OSI Interoperability Workshop,
using the padding conventions described in PKCS1.
NONEwithDSA
The Digital Signature Algorithm as defined in FIPS
PUB 186-2. The data must be exactly 20 bytes in length.
This algorithms is also known under the alias name of rawDSA.
SHA1withDSA
The DSA with SHA-1 signature algorithm which uses the SHA-1
digest algorithm and DSA to create and verify DSA digital
signatures as defined in FIPS
PUB 186.
The ECDSA signature algorithms as defined in ANSI X9.62.
Note:"ECDSA" is an ambiguous name for the
"SHA1withECDSA" algorithm and should not be used. The formal
name "SHA1withECDSA" should be used instead.
<digest>with<encryption>
Use this to form a name for a signature algorithm with a
particular message digest (such as MD2 or MD5) and algorithm
(such as RSA or DSA), just as was done for the
explicitly-defined standard names in this section (MD2withRSA,
etc.).
For the new signature schemes defined in
PKCS1 v 2.0,
for which the <digest>with<encryption> form is
insufficient,
<digest>with<encryption>and<mgf> can
be used to form a name. Here, <mgf> should be replaced by
a mask generation function such as MGF1. Example:
MD5withRSAandMGF1.
The algorithm names in this section can be specified when generating an
instance of TrustManagerFactory.
Alg. Name
Description
PKIX
A factory for X509TrustManagers which validate certificate chains
according to the rules defined by the IETF PKIX working group in RFC 3280 or its
successor. The TrustManagerFactory must support initialization using
the class javax.net.ssl.CertPathTrustManagerParameters.
The keyType parameter passed to the
chooseClientAlias, chooseServerAlias,
getClientAliases, and getServerAliases
methods of X509KeyManager specify the public key type(s).
Each row of the table below lists the standard name that should be used
for keyType, given the specified certificate type.
Name
Certificate Type
RSA
RSA
DSA
DSA
DH_RSA
Diffie-Hellman with RSA signature
DH_DSA
Diffie-Hellman with DSA signature
EC
Elliptic Curve
EC_EC
Elliptic Curve with ECDSA signature
EC_RSA
Elliptic Curve with RSA signature
The protocols parameter passed to the
setEnabledProtocols method of SSLSocket
specifies the protocol versions to be enabled for use on the
connection. The table below lists the standard names that can be passed
to setEnabledProtocols or that may be returned by the
SSLSocket getSupportedProtocols and
getEnabledProtocols methods.
Currently, the SSLv3, TLSv1, and TLSv1.1 protocols allow you to
send SSLv3, TLSv1, and
TLSv1.1 hellos encapsulated in an SSLv2 format hello. For more details on
the reasons for allowing this compatibility in these protocols, see
Appendix E in the appropriate RFCs (above).
Note that some SSL/TLS servers do not support the v2 hello
format
and require that client hellos conform to the SSLv3 or TLSv1 client
hello
formats.
The SSLv2Hello option controls the SSLv2 encapsulation.
If SSLv2Hello is disabled on the client, then all outgoing messages
will conform to the SSLv3/TLSv1 client hello format. If SSLv2Hello
is disabled on the server, then all incoming messages must conform
to the SSLv3/TLSv1 client hello format.
The authType parameter passed to the
checkClientTrusted and checkServerTrusted
methods of X509TrustManager indicates the authentication
type. The table below specifies what standard names should be used for
the client or server certificate chains.
Client or Server Certificate Chain
Authentication Type Standard Name
Client
Determined by the actual certificate used. For instance,
if RSAPublicKey is used, the authType should be "RSA".
Server
The key exchange algorithm portion of the cipher suites
represented as a String, such as "RSA" or "DHE_DSS". Note: For some
exportable cipher suites, the key exchange algorithm is determined at
run time during the handshake. For instance, for
TLS_RSA_EXPORT_WITH_RC4_40_MD5, the authType should be
"RSA_EXPORT" when an ephemeral RSA key is used for the key exchange,
and "RSA" when the key from the server certificate is used. Or it can
take the value "UNKNOWN".
Over time, various groups have added new ciphersuites definitions to
the SSL/TLS namespace. Some ciphersuite names were defined before
TLSv1.0 was finalized, and were therefore given the SSL_*
prefix. The names mentioned in the TLS RFC prefixed with
TLS_* are functionally equivalent to the JSSE ciphersuites
prefixed with SSL_*.
The following table lists the standard cipher suite names:
This Section specifies details concerning some of the algorithms
defined in this document. Any provider supplying an implementation of
the listed algorithms must comply with the specifications in this
appendix.
To add a new algorithm not specified here, you should first
survey other people or companies supplying provider
packages to see if they
have already added that algorithm, and, if so, use
the definitions they published, if available. Otherwise, you
should create and make available a
template, similar to those found in this Section,
with the specifications for the algorithm you
provide.
The following table shows the fields of the algorithm specifications.
Field
Description
Name
The name by which the algorithm is known. This is the name passed
to the getInstance method (when requesting the
algorithm), and returned by the getAlgorithm method to
determine the name of an existing algorithm object. These methods
are in the relevant engine classes: Signature, MessageDigest, KeyPairGenerator, and AlgorithmParameterGenerator.
Type
The type of algorithm: Signature, MessageDigest,
KeyPairGenerator, or ParameterGenerator.
Description
General notes about the algorithm, including any standards implemented
by the algorithm, applicable patents, etc.
KeyPair Algorithm (optional)
The keypair algorithm for this algorithm.
Keysize (optional)
For a keyed algorithm or key generation algorithm: the legal
keysizes.
Size (optional)
For an algorithm parameter generation algorithm: the legal "sizes"
for algorithm parameter generation.
Parameter Defaults (optional)
For a key generation algorithm: the default parameter values.
Signature Format (optional)
For a Signature algorithm, the format of the signature,
that is, the input and output of the verify and sign methods,
respectively.
This section defines the security algorithm requirements for Java SE 6
implementations. These requirements are intended to improve the
interoperability of Java SE 6 implementations and applications that
use these algorithms.
The implementation requirements are one of two types:
RECOMMENDED:
Each implementation of Java SE 6 should, by default (as installed),
support the specified algorithm(s).
REQUIRED:
Each implementation of Java SE 6 must, by default (as installed),
support the specified algorithm(s).
Note that the requirements in this section are not a measure of the
strength or security of the algorithm. For example, recent advances in
cryptanalysis have found weaknesses in the strength of the MD5 MessageDigest
algorithm. It is your responsibility to determine whether the algorithm meets
the security requirements of your application.
If an algorithm or engine is not listed, then it is not subject to the
specified requirement.
Java Cryptography and PKI Algorithms
Each implementation of Java SE 6 should, by default (as installed),
support the specified algorithms (all RECOMMENDED) in the table below.
For the next release of Java SE (7), the plan is that each algorithm
in the table below will be changed to REQUIRED. These requirements do not
apply to 3rd party providers.
Engine
Algorithm Name(s)
Requirement
AlgorithmParameters
DSA
RECOMMENDED
CertificateFactory
X.509
RECOMMENDED
CertPathBuilder
PKIX
RECOMMENDED
CertPathValidator
PKIX
RECOMMENDED
CertStore
Collection
RECOMMENDED
Cipher (the algorithms are specified as
transformations). Implementations
must support up to the key size in parentheses.