4 JDK Providers Documentation
This document contains the technical details of the providers that are included in the JDK. It is assumed that readers have a strong understanding of the Java Cryptography Architecture and Provider Architecture.
Note:
The Java Security Standard Algorithm Names contains more information about the standard names used in this document.Introduction to JDK Providers
The Java platform defines a set of APIs spanning major security areas, including cryptography, public key infrastructure, authentication, secure communication, and access control. These APIs enable developers to easily integrate security mechanisms into their application code.
The Java Cryptography Architecture (JCA) and its Provider Architecture are core concepts of the Java Development Kit (JDK). It is assumed that readers have a solid understanding of this architecture.
Reminder: Cryptographic implementations in the JDK are distributed through several different providers ("SUN", "SunJSSE", "SunJCE", "SunRsaSign") for both historical reasons and by the types of services provided. General purpose applications SHOULD NOT request cryptographic services from specific providers. That is:
getInstance("...", "SunJCE"); // not recommended
versus
getInstance("..."); // recommended
Otherwise, applications are tied to specific providers that may not be available on other Java implementations. They also might not be able to take advantage of available optimized providers (for example, hardware accelerators via PKCS11 or native OS implementations such as Microsoft's MSCAPI) that have a higher preference order than the specific requested provider.
The following table lists the modules and the supported Java Cryptographic Service Providers:
Table 4-1 Modules and the Java Cryptographic Service Providers
Module | Provider(s) |
---|---|
java.base |
SUN, SunRsaSign, SunJSSE, SunJCEFoot 1, Apple |
java.naming |
JdkLDAP |
java.security.jgss |
SunJGSS |
java.security.sasl |
SunSASL |
java.smartcardio |
SunPCSC |
java.xml.crypto |
XMLDSig |
jdk.crypto.cryptoki |
SunPKCS11Foot 1 |
jdk.crypto.ec |
SunECFoot 1 |
jdk.crypto.mscapi |
SunMSCAPIFoot 1 |
jdk.security.jgss |
JdkSASL |
Footnote 1 Indicates JCE crypto providers previously distributed as signed JAR files (JCE providers contain Cipher/KeyAgreement/KeyGenerator/Mac/SecretKeyFactory
implementations).
Import Limits on Cryptographic Algorithms
By default, an application can use cryptographic algorithms of any strength. However, due to import regulations in some locations, you may have to limit the strength of those algorithms. The JDK provides two different sets of jurisdiction policy files in the directory <java-home>/conf/security/policy
that determine the strength of cryptographic algorithms. Information about jurisdiction policy files and how to activate them is available in Cryptographic Strength Configuration.
Consult your export/import control counsel or attorney to determine the exact requirements for your location.
For the "limited" configuration, the following table lists the maximum key sizes allowed by the "limited" set of jurisdiction policy files:
Table 4-2 Maximum Keysize of Cryptographic Algorithms
Algorithm | Maximum Keysize |
---|---|
DES | 64 |
DESede | * |
RC2 | 128 |
RC4 | 128 |
RC5 | 128 |
RSA | * |
all others | 128 |
Cipher Transformations
The javax.crypto.Cipher.getInstance(String transformation)
factory method generates Cipher
objects using transformations of the form algorithm/mode/padding. If the mode/padding are omitted, the SunJCE and SunPKCS11 providers use ECB as the default mode and PKCS5Padding as the default padding for many symmetric ciphers.
It is recommended to use transformations that fully specify the algorithm, mode, and padding instead of relying on the defaults. The defaults are provider specific and can vary among providers.
Note:
ECB mode is the easiest block cipher mode to use and is the default cipher mode. ECB works well for single blocks of data and can be parallelized but generally should not be used for encrypting multiple data blocks due to characteristics of the mode. This could result in trivial and full disclosure of confidential data. While this mode is available for use, it should only be used with an understanding of the cryptographic risks involved.SecureRandom Implementations
The following table lists the default preference order of the available SecureRandom
implementations.
Table 4-3 Default SecureRandom Implementations
OS | Algorithm Name | Provider Name |
---|---|---|
Linux | 1. NativePRNGFoot 2 | SUN |
2. DRBG | SUN | |
3. SHA1PRNG Foot 2 | SUN | |
4. NativePRNGBlocking | SUN | |
5. NativePRNGNonBlocking | SUN | |
macOS | 1. NativePRNGFoot 2 | SUN |
2. DRBG | SUN | |
3. SHA1PRNGFoot 2 | SUN | |
4. NativePRNGBlocking | SUN | |
5. NativePRNGNonBlocking | SUN | |
Windows | 1. DRBG | SUN |
2. SHA1PRNG | SUN | |
3. Windows-PRNGFoot 3 | SunMSCAPI |
Footnote 2 On Linux and macOS, if
the entropy gathering device in
java.security
is set to
file:/dev/urandom
or
file:/dev/random
, then NativePRNG is
preferred to SHA1PRNG. Otherwise, SHA1PRNG is preferred.
Footnote 3 There is currently no NativePRNG on Windows. Access to the equivalent functionality is via the SunMSCAPI provider.
The SunPKCS11 Provider
The Cryptographic Token Interface Standard (PKCS#11) provides native programming interfaces to
cryptographic mechanisms, such as hardware cryptographic accelerators and Smart
Cards. When properly configured, the SunPKCS11
provider enables
applications to use the standard JCA/JCE APIs to access native PKCS#11 libraries.
The SunPKCS11
provider itself does not contain cryptographic
functionality, it is simply a conduit between the Java environment and the
native PKCS11 providers. The PKCS#11 Reference Guide has
a much more detailed treatment of this provider.
The SUN Provider
Algorithms
The following algorithms are available in the SUN
provider:
Table 4-4 Algorithms in SUN provider
Engine | Algorithm Names |
---|---|
AlgorithmParameterGenerator |
DSA |
AlgorithmParameters |
DSA |
CertificateFactory |
X.509 |
CertPathBuilder |
PKIX |
CertPathValidator |
PKIX |
CertStore |
Collection |
Configuration |
JavaLoginConfig |
KeyFactory |
DSA HSS/LMSFoot 4 |
KeyPairGenerator |
DSA |
KeyStore |
PKCS12Foot 5 JKS DKS CaseExactJKS |
MessageDigest |
MD2 MD5 SHA-1 SHA-224 SHA-256 SHA-384 SHA-512 SHA-512/224 SHA-512/256 SHA3-224 SHA3-256 SHA3-384 SHA3-512 |
Policy |
JavaPolicy |
SecureRandom |
DRBG (The following mechanisms and algorithms are supported: Hash_DRBG and HMAC_DRBG with SHA-224, SHA-512/224, SHA-256, SHA-512/256, SHA-384 and SHA-512. CTR_DRBG (both use derivation function and not use) with AES-128, AES-192 and AES-256. Prediction resistance and reseeding supported for each combination, and security strength can be requested from 112 up to the highest strength one supports.) SHA1PRNG (Initial seeding is currently done via a combination
of system attributes and the NativePRNG ( NativePRNGBlocking ( NativePRNGNonBlocking ( |
Signature |
HSS/LMSFoot 6 NONEwithDSA SHA1withDSA SHA224withDSA SHA256withDSA SHA384withDSA SHA512withDSA NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format SHA384withDSAinP1363Format SHA512withDSAinP1363Format SHA3-224withDSA SHA3-256withDSA SHA3-384withDSA SHA3-512withDSA SHA3-224withDSAinP1363Format SHA3-256withDSAinP1363Format SHA3-384withDSAinP1363Format SHA3-512withDSAinP1363Format Note: For signature generation, if the security strength of the digest algorithm is weaker than the security strength of the key used to sign the signature (for example, using (2048, 256)-bit DSA keys with the SHA1withDSA signature), then the operation will fail with the error message: "The security strength of SHA1 digest algorithm is not sufficient for this key size." |
Footnote 4 The KeyFactory implementation of HSS/LMS supports only public key management. An InvalidKeySpecException is thrown if the generatePrivate method is called or the getKeySpec and translateKey methods are called with a private key.
Footnote 5
The PKCS12 KeyStore implementation does not support the KeyBag type.
You can create a password-less PKCS12 keystore file by calling the KeyStore.store() method with a null password. The certificates in this keystore are stored unencrypted, and no MacData is added. This keystore can be loaded with any password (including null). Note that keys in a keystore are always stored encrypted.
Footnote 6 The Signature implementation of HSS/LMS only supports signature verification. An InvalidKeyException is thrown if the initSign method is called with a private key.
Object Identifiers Associated with SHA Message Digests and DSA Signatures
The following table lists object identifiers (OIDs) associated with SHA Message Digests:
Table 4-5 OIDs associated with SHA Message Digests
SHA Message Digest | OID |
---|---|
SHA-224 | 2.16.840.1.101.3.4.2.4 |
SHA-256 | 2.16.840.1.101.3.4.2.1 |
SHA-384 | 2.16.840.1.101.3.4.2.2 |
SHA-512 | 2.16.840.1.101.3.4.2.3 |
SHA-512/224 | 2.16.840.1.101.3.4.2.5 |
SHA-512/256 | 2.16.840.1.101.3.4.2.6 |
SHA3-224 | 2.16.840.1.101.3.4.2.7 |
SHA3-256 | 2.16.840.1.101.3.4.2.8 |
SHA3-384 | 2.16.840.1.101.3.4.2.9 |
SHA3-512 | 2.16.840.1.101.3.4.2.10 |
The following table lists OIDs associated with DSA Signatures:
Table 4-6 OIDs associated with DSA Signatures
DSA Signature | OID |
---|---|
SHA1withDSA |
1.2.840.10040.4.3 1.3.14.3.2.13 1.3.14.3.2.27 |
SHA224withDSA | 2.16.840.1.101.3.4.3.1 |
SHA256withDSA | 2.16.840.1.101.3.4.3.2 |
SHA384withDSA | 2.16.840.1.101.3.4.3.3 |
SHA512withDSA | 2.16.840.1.101.3.4.3.4 |
SHA3-224withDSA | 2.16.840.1.101.3.4.3.5 |
SHA3-256withDSA | 2.16.840.1.101.3.4.3.6 |
SHA3-384withDSA | 2.16.840.1.101.3.4.3.7 |
SHA3-512withDSA | 2.16.840.1.101.3.4.3.8 |
Keysize Restrictions
The SUN
provider uses the following default keysizes (in bits) and enforces the following restrictions:
Table 4-7 KeyPairGenerator Algorithm Keysize Restrictions
Algorithm Name | Default Keysize | Restrictions/Comments |
---|---|---|
DSA | 2048 | Keysize must be a multiple of 64, ranging from 512 to 1024, plus 2048 and 3072. |
Table 4-8 AlgorithmParameterGenerator Algorithm Keysize Restrictions
Algorithm Name | Default Keysize | Restrictions/Comments |
---|---|---|
DSA | 2048 | Keysize must be a multiple of 64, ranging from 512 to 1024, plus 2048 and 3072. |
CertificateFactory/CertPathBuilder/CertPathValidator/CertStore Implementations
See Appendix B: CertPath Implementation in SUN Provider in the Java PKI
Programmer's Guide Additional details on the SUN
provider
implementations for CertificateFactory
,
CertPathBuilder
, CertPathValidator
and
CertStore
are documented in of the .
The SunRsaSign Provider
Algorithms
The following algorithms are available in the
SunRsaSign
provider:
Table 4-9 SunRsaSign Provider Algorithm Names for Engine Classes
Engine | Algorithm Names |
---|---|
AlgorithmParameters |
RSASSA-PSS |
KeyFactory |
RSA RSASSA-PSS |
KeyPairGenerator |
RSA RSASSA-PSS |
Signature |
MD2withRSA MD5withRSA SHA1withRSA SHA224withRSA SHA256withRSA SHA384withRSA SHA512withRSA SHA512/224withRSA SHA512/256withRSA SHA3-224withRSA SHA3-256withRSA SHA3-384withRSA SHA3-512withRSA RSASSA-PSS |
Keysize Restrictions
The SunRsaSign
provider uses the following default keysize (in bits) and enforces the following restriction:
Table 4-10 SunRsaSign Provider Keysize Restrictions
Alg. Name | Default Keysize | Restrictions/Comments |
---|---|---|
RSA and RSASSA-PSS | 3072 | Keysize must range between 512 and 16384 bits. If the key size exceeds 3072, then the public exponent length cannot exceed 64 bits. |
The SunJSSE Provider
Algorithms
The following algorithms are available in the
SunJSSE
provider:
Table 4-11 Algorithms in SunJSSE Provider
Engine | Algorithm Name(s) |
---|---|
KeyManagerFactory |
PKIX: A factory for
SunX509: A factory for
Note: The SunX509 factory is for backwards compatibility with older releases, and should no longer be used. |
KeyStore |
PKCS12 Note: The SunJSSE provider is for backwards
compatibility with older releases, and should no longer be used
for |
SSLContext |
SSL SSLv3 TLS TLSv1 TLSv1.1 TLSv1.2 TLSv1.3 DTLS DTLSv1.0 DTLSv1.2 |
TrustManagerFactory |
PKIX: A factory for
SunX509: A factory for
Note: The SunX509 factory is for backwards compatibility with older releases, and should no longer be used. |
SunJSSE Provider Protocol Parameters
The SunJSSE
provider supports the
protocol
parameters listed in Table 4-12.
Table 4-12 SunJSSE Provider Protocol Versions
Protocol Version | Enabled by Default for Client | Enabled by Default for Server |
---|---|---|
SSLv3 |
No | No |
TLSv1Foot 7 | Yes | Yes |
TLSv1.1Foot 7 | Yes | Yes |
TLSv1.2 | Yes | Yes |
TLSv1.3 | Yes | Yes |
SSLv2Hello | No | No |
DTLSv1.0 | Yes | Yes |
DTLSv1.2 | Yes | Yes |
Footnote 7 TLS 1.0 and 1.1 are versions of the
TLS protocol that are no longer considered secure and have been
superseded by more secure and modern versions (TLS 1.2 and 1.3).
These versions have now been disabled by default. If you
encounter issues, you can, at your own risk, re-enable the
versions by removing TLSv1
or
TLSv1.1
from the
jdk.tls.disabledAlgorithms
Security
Property in the java.security
configuration
file.
Note:
The protocols available by default in a JDK release change as new protocols are developed and old protocols are found to be less effective than previously thought. The JDK uses two mechanisms to restrict the availability of these protocols:
- The
jdk.tls.disabledAlgorithms
Security Property: This disables categories of protocols and cipher suites. For example, if this Security Property containsSSLv3
, then the SSLv3 protocol would be disabled. See Disabled and Restricted Cryptographic Algorithms for information about this Security Property. - Moving the protocol to the list of protocols not enabled by default as indicated in Table 4-12.
The enabled protocol versions of an SSLContext implementation may differ from the default values in the previous table depending on the algorithm and its mode (client or server). The following tables list the enabled protocol versions for SSLContext implementations that differ from the default:
Table 4-13 Enabled Protocol Versions for Specific SSLContext Implementations in Client Mode
SSLContext Algorithm | SSL/TLS/DTLS Protocol Version | |||||||
---|---|---|---|---|---|---|---|---|
SSLv2Hello | SSLv3 | TLSv1 | TLSv1.1 | TLSv1.2 | TLSv1.3 | DTLSv1.0 | DTLSv1.2 | |
SSLv3 | No | No | Yes | No | No | No | N/A | N/A |
TLSv1 | No | No | Yes | No | No | No | N/A | N/A |
TLSv1.1 | No | No | Yes | Yes | No | No | N/A | N/A |
TLSv1.2 | No | No | Yes | Yes | Yes | No | N/A | N/A |
TLSv1.3 | No | No | Yes | Yes | Yes | Yes | N/A | N/A |
Default | No | No | Yes | Yes | Yes | Yes | N/A | N/A |
TLS | No | No | Yes | Yes | Yes | Yes | N/A | N/A |
SSL | No | No | Yes | Yes | Yes | Yes | N/A | N/A |
DTLSv1.0 | N/A | N/A | N/A | N/A | N/A | N/A | Yes | No |
DTLSv1.2 | N/A | N/A | N/A | N/A | N/A | N/A | Yes | Yes |
DTLS | N/A | N/A | N/A | N/A | N/A | N/A | Yes | Yes |
Table 4-14 Enabled Protocol Versions for Specific SSLContext Implementations in Server Mode
SSLContext Algorithm | SSL/TLS/DTLS Protocol Version | |||||||
---|---|---|---|---|---|---|---|---|
SSLv2Hello | SSLv3 | TLSv1 | TLSv1.1 | TLSv1.2 | TLSv1.3 | DTLSv1.0 | DTLSv1.2 | |
SSLv3 | No | No | Yes | Yes | Yes | Yes | N/A | N/A |
TLSv1 | No | No | Yes | Yes | Yes | Yes | N/A | N/A |
TLSv1.1 | No | No | Yes | Yes | Yes | Yes | N/A | N/A |
TLSv1.2 | No | No | Yes | Yes | Yes | Yes | N/A | N/A |
TLSv1.3 | No | No | Yes | Yes | Yes | Yes | N/A | N/A |
Default | No | No | Yes | Yes | Yes | Yes | N/A | N/A |
TLS | No | No | Yes | Yes | Yes | Yes | N/A | N/A |
SSL | No | No | Yes | Yes | Yes | Yes | N/A | N/A |
DTLSv1.0 | N/A | N/A | N/A | N/A | N/A | N/A | Yes | Yes |
DTLSv1.2 | N/A | N/A | N/A | N/A | N/A | N/A | Yes | Yes |
DTLS | N/A | N/A | N/A | N/A | N/A | N/A | Yes | Yes |
SunJSSE Cipher Suites
The following are the currently implemented SunJSSE cipher suites for this JDK release, sorted by order of preference. Not all of these cipher suites are available for use by default. See JSSE Cipher Suite Names in Java Security Standard Algorithm Names to determine which protocols that each cipher suite supports.
- TLS_AES_128_GCM_SHA256
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_RSA_WITH_AES_256_CBC_SHA256
- TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
- SSL_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
- SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
- SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
- TLS_EMPTY_RENEGOTIATION_INFO_SCSV
- TLS_DH_anon_WITH_AES_256_GCM_SHA384
- TLS_DH_anon_WITH_AES_128_GCM_SHA256
- TLS_DH_anon_WITH_AES_256_CBC_SHA256
- TLS_ECDH_anon_WITH_AES_256_CBC_SHA
- TLS_DH_anon_WITH_AES_256_CBC_SHA
- TLS_DH_anon_WITH_AES_128_CBC_SHA256
- TLS_ECDH_anon_WITH_AES_128_CBC_SHA
- TLS_DH_anon_WITH_AES_128_CBC_SHA
- TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
- SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
- TLS_ECDHE_RSA_WITH_RC4_128_SHA
- SSL_RSA_WITH_RC4_128_SHA
- TLS_ECDH_ECDSA_WITH_RC4_128_SHA
- TLS_ECDH_RSA_WITH_RC4_128_SHA
- SSL_RSA_WITH_RC4_128_MD5
- TLS_ECDH_anon_WITH_RC4_128_SHA
- SSL_DH_anon_WITH_RC4_128_MD5
- SSL_RSA_WITH_DES_CBC_SHA
- SSL_DHE_RSA_WITH_DES_CBC_SHA
- SSL_DHE_DSS_WITH_DES_CBC_SHA
- SSL_DH_anon_WITH_DES_CBC_SHA
- SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
- SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
- SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
- SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
- SSL_RSA_EXPORT_WITH_RC4_40_MD5
- SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
- TLS_RSA_WITH_NULL_SHA256
- TLS_ECDHE_ECDSA_WITH_NULL_SHA
- TLS_ECDHE_RSA_WITH_NULL_SHA
- SSL_RSA_WITH_NULL_SHA
- TLS_ECDH_ECDSA_WITH_NULL_SHA
- TLS_ECDH_RSA_WITH_NULL_SHA
- TLS_ECDH_anon_WITH_NULL_SHA
- SSL_RSA_WITH_NULL_MD5
Note:
- The cipher suite order of preference may change in future releases.
- TLS_EMPTY_RENEGOTIATION_INFO_SCSV is a pseudo-cipher suite that supports RFC 5746.
The cipher suites available by default in a JDK release change as new algorithms are developed and old algorithms are found to be less effective than previously thought. Oracle JDK uses two mechanisms to restrict the availability of these algorithms:
- The
jdk.tls.disabledAlgorithms
Security Property, which disables categories of cipher suites. For example, if this Security Property containsRC4
, then all RC4-based cipher suites would be disabled. - Moving the cipher suite to the list of suites not enabled by default.
See Disabled and Restricted Cryptographic Algorithms for information about the
jdk.tls.disabledAlgorithms
Security Property.
Determining Current List of Protocols and Cipher Suites Available by Default
To obtain the current list of protocols and cipher suites that are available by default, run the following command:
keytool -showinfo -tls
Note that the list generated by this command doesn't include suites that the
jdk.tls.disabledAlgorithms
Security Property disabled.
Tighter Checking of EncryptedPreMasterSecret Version Numbers
Prior to the JDK 7
release, the SSL/TLS implementation did not check the version number in
PreMasterSecret, and the SSL/TLS client did not send the correct version number by
default. Unless the system property
com.sun.net.ssl.rsaPreMasterSecretFix
is set to
true
, the TLS client sends the active negotiated version, but
not the expected maximum version supported by the client.
For
compatibility, this behavior is preserved for SSL version 3.0 and TLS version 1.0.
However, for TLS version 1.1 or later, the implementation tightens checking the
PreMasterSecret version numbers as required by RFC 5246.
Clients always send the correct version number, and servers check the version number
strictly. The system property,
com.sun.net.ssl.rsaPreMasterSecretFix
, is not used in TLS 1.1
or later.
The SunJCE Provider
As described briefly in The SUN Provider, US export regulations at the time restricted the type of cryptographic functionality that could be available in the JDK. A separate API and reference implementation was developed that allowed applications to encrypt/decrypt date. The Java Cryptographic Extension (JCE) was released as a separate ”Optional Package” (also briefly known as a “Standard Extension”), and was available for JDK 1.2x and 1.3x. During the development of JDK 1.4, regulations were relaxed enough that JCE (and SunJSSE) could be bundled as part of the JDK.
The following algorithms are available in the SunJCE provider:
Note:
The SunJCE provider only supports ASCII for passwords for its PBE algorithms.Table 4-15 The SunJCE Provider Algorithm Names for Engine Classes
Engine | Algorithm Names |
---|---|
AlgorithmParameterGenerator |
DiffieHellman |
AlgorithmParameters |
AES Blowfish ChaCha20-Poly1305 DES DESede DiffieHellman GCM OAEP PBE PBES2 PBEWithHmacSHA1AndAES_128 PBEWithHmacSHA224AndAES_128 PBEWithHmacSHA256AndAES_128 PBEWithHmacSHA384AndAES_128 PBEWithHmacSHA512AndAES_128 PBEWithHmacSHA512/224AndAES_128 PBEWithHmacSHA512/256AndAES_128 PBEWithHmacSHA1AndAES_256 PBEWithHmacSHA224AndAES_256 PBEWithHmacSHA256AndAES_256 PBEWithHmacSHA384AndAES_256 PBEWithHmacSHA512/224AndAES_256 PBEWithHmacSHA512/256AndAES_256 PBEWithHmacSHA512AndAES_256 PBEWithMD5AndDES PBEWithMD5AndTripleDES PBEWithSHA1AndDESede PBEWithSHA1AndRC2_40 PBEWithSHA1AndRC2_128 PBEWithSHA1AndRC4_40 PBEWithSHA1AndRC4_128 RC2 |
Cipher |
See Table 4-16 |
KEM | DHKEMFoot 8 |
KeyAgreement |
DiffieHellman |
KeyFactory |
DiffieHellman |
KeyGenerator |
AES ARCFOUR Blowfish ChaCha20 DES DESede HmacMD5 HmacSHA1 HmacSHA224 HmacSHA256 HmacSHA384 HmacSHA512 HmacSHA512/224 HmacSHA512/256 HmacSHA3-224 HmacSHA3-256 HmacSHA3-384 HmacSHA3-512 RC2 |
KeyPairGenerator |
DiffieHellman |
KeyStore |
JCEKS |
Mac |
HmacMD5 HmacSHA1 HmacSHA224 HmacSHA256 HmacSHA384 HmacSHA512 HmacSHA512/224 HmacSHA512/256 HmacSHA3-224 HmacSHA3-256 HmacSHA3-384 HmacSHA3-512 HmacPBESHA1 HmacPBESHA224 HmacPBESHA256 HmacPBESHA384 HmacPBESHA512 HmacPBESHA512/224 HmacPBESHA512/256 PBEWithHmacSHA1 PBEWithHmacSHA224 PBEWithHmacSHA256 PBEWithHmacSHA384 PBEWithHmacSHA512 PBEWithHmacSHA512/224 PBEWithHmacSHA512/256 |
SecretKeyFactory |
DES DESede PBEWithMD5AndDES PBEWithMD5AndTripleDES PBEWithSHA1AndDESede PBEWithSHA1AndRC2_40 PBEWithSHA1AndRC2_128 PBEWithSHA1AndRC4_40 PBEWithSHA1AndRC4_128 PBEWithHmacSHA1AndAES_128 PBEWithHmacSHA224AndAES_128 PBEWithHmacSHA256AndAES_128 PBEWithHmacSHA384AndAES_128 PBEWithHmacSHA512AndAES_128 PBEWithHmacSHA512/224AndAES_128 PBEWithHmacSHA512/256AndAES_128 PBEWithHmacSHA1AndAES_256 PBEWithHmacSHA224AndAES_256 PBEWithHmacSHA256AndAES_256 PBEWithHmacSHA384AndAES_256 PBEWithHmacSHA512/224AndAES_256 PBEWithHmacSHA512/256AndAES_256 PBEWithHmacSHA512AndAES_256 PBKDF2WithHmacSHA1 PBKDF2WithHmacSHA224 PBKDF2WithHmacSHA256 PBKDF2WithHmacSHA384 PBKDF2WithHmacSHA512 PBKDF2WithHmacSHA512/224 PBKDF2WithHmacSHA512/256 |
Footnote 8 The DHKEM algorithm accepts EC keys on the secp256r1, secp384r1, and secp521r1 curves and XDH keys on Curve25519 and Curve448.
The following table lists cipher transformations available in the SunJCE provider.
Table 4-16 The SunJCE Provider Cipher Transformations
Algorithm Names | Modes | Paddings |
---|---|---|
AES | ECB, CBC, PCBC, CFBFoot 9, CFB8..CFB128, OFBFoot 9, OFB8..OFB128 | NoPadding, PKCS5Padding, ISO10126PaddingFoot 10 |
AES | CTR, CTS, GCM | NoPadding |
AES_128, AES_192, AES_256 | ECB, CBC, OFB, CFB, GCM | NoPadding |
AESWrap | ECB | NoPadding |
AESWrap_128 | ECB | NoPadding |
AESWrap_192 | ECB | NoPadding |
AESWrap_256 | ECB | NoPadding |
ARCFOUR | ECB | NoPadding |
Blowfish, DES, DESede, RC2 | ECB, CBC, PCBC, CTR, CTS, CFBFoot 9, CFB8..CFB64, OFBFoot 9, OFB8..OFB64 | NoPadding, PKCS5Padding, ISO10126Padding |
ChaCha20 | None | NoPadding |
ChaCha20-Poly1305 | None | NoPadding |
DESedeWrap | CBC | NoPadding |
PBEWithHmacSHA1AndAES_128, PBEWithHmacSHA224AndAES_128, PBEWithHmacSHA256AndAES_128, PBEWithHmacSHA384AndAES_128, PBEWithHmacSHA512AndAES_128, PBEWithHmacSHA512/224AndAES_128, PBEWithHmacSHA512/256AndAES_128, PBEWithHmacSHA1AndAES_256, PBEWithHmacSHA224AndAES_256, PBEWithHmacSHA256AndAES_256, PBEWithHmacSHA384AndAES_256, PBEWithHmacSHA512/224AndAES_256, PBEWithHmacSHA512/256AndAES_256, PBEWithHmacSHA512AndAES_256, PBEWithMD5AndDES, PBEWithMD5AndTripleDESFoot 11, PBEWithSHA1AndDESede, PBEWithSHA1AndRC2_40, PBEWithSHA1AndRC2_128, PBEWithSHA1AndRC4_40, PBEWithSHA1AndRC4_128 |
CBC | PKCS5Padding |
RSA | ECB |
NoPadding, PKCS1Padding, OAEPPadding, OAEPWithMD5AndMGF1Padding, OAEPWithSHA‑1AndMGF1Padding, OAEPWithSHA‑1AndMGF1Padding, OAEPWithSHA‑224AndMGF1Padding, OAEPWithSHA‑256AndMGF1Padding, OAEPWithSHA‑384AndMGF1Padding, OAEPWithSHA‑512AndMGF1Padding, OAEPWithSHA‑512/224AndMGF1Padding, OAEPWithSHA‑512/256AndMGF1Padding |
Footnote 9 CFB/OFB with no specified value defaults to the block size of the algorithm. (i.e. AES is 128; Blowfish, DES, DESede, and RC2 are 64.)
Footnote 10 Though the standard doesn't specify or require the padding bytes to be random, the Java SE ISO10126Padding implementation pads with random bytes (until the last byte, which provides the length of padding, as specified).
Footnote 11 PBEWithMD5AndTripleDES is a proprietary algorithm that has not been standardized.
Keysize Restrictions
The SunJCE provider uses the following default key sizes (in bits) and enforces the following restrictions:
KeyGenerator
Table 4-17 The SunJCE Provider Key Size Restrictions
Algorithm Name | Default Key size | Restrictions/Comments |
---|---|---|
AES | 256 if permitted by the cryptographic policy (see Import Limits on Cryptographic Algorithms), 128 otherwise | Key size must be equal to 128, 192, or 256. |
ARCFOUR (RC4) | 128 | Key size must range between 40 and 1024 (inclusive). |
Blowfish | 128 | Key size must be a multiple of 8, ranging from 32 to 448 (inclusive). |
ChaCha20 | 256 | Key size must be equal to 256. |
DES | 56 | Key size must be equal to 56. |
DESede (Triple DES) | 168 |
Key size must be equal to 112 or 168. A key size of 112 will generate a Triple DES key with 2 intermediate keys, and a key size of 168 will generate a Triple DES key with 3 intermediate keys. Due to the "Meet-In-The-Middle" problem, even though 112 or 168 bits of key material are used, the effective key size is 80 or 112 bits respectively. |
HmacMD5 | 512 | No key size restriction. |
HmacSHA1 | 512 | No key size restriction. |
HmacSHA224 | 224 | No key size restriction. |
HmacSHA256 | 256 | No key size restriction. |
HmacSHA384 | 384 | No key size restriction. |
HmacSHA512 | 512 | No key size restriction. |
RC2 | 128 | Key size must range between 40 and 1024 (inclusive). |
Note:
The various Password-Based Encryption (PBE) algorithms use various algorithms to generate key data, and ultimately depends on the targeted Cipher algorithm. For example, PBEWithMD5AndDES will always generate 56–bit keys.
Table 4-18 KeyPairGenerator
Algorithm Name | Default Key size | Restrictions/Comments |
---|---|---|
Diffie-Hellman (DH) | 3072 | Key size must be a multiple of 64, ranging from 512 to 1024, plus 1536, 2048, 3072, 4096, 6144, 8192. |
Table 4-19 AlgorithmParameterGenerator
Algorithm Name | Default Key size | Restrictions/Comments |
---|---|---|
Diffie-Hellman (DH) | 3072 | Key size must be a multiple of 64, ranging from 512 to 1024, plus 2048 and 3072. |
The SunJGSS Provider
Algorithms
The following algorithms are available in the SunJGSS provider:
Table 4-20 SunJGSS Provider Algorithm Names
OID | Name |
---|---|
1.2.840.113554.1.2.2 |
Kerberos v5 |
1.3.6.1.5.5.2 |
SPNEGO |
The SunSASL Provider
Algorithms
The following algorithms are available in the SunSASL
provider:
Table 4-21 SunSASL Provider Algorithm Names for Engine Classes
Engine | Algorithm Names |
---|---|
SaslClient |
CRAM-MD5 DIGEST-MD5 EXTERNAL NTLM PLAIN |
SaslServer |
CRAM-MD5 DIGEST-MD5 NTLM |
The XMLDSig Provider
Algorithms
The following algorithms are available in the XMLDSig
provider:
Table 4-22 XMLDSig Provider Algorithm Names for Engine Classes
Engine | Algorithm Names |
---|---|
KeyInfoFactory |
DOM |
TransformService |
|
XMLSignatureFactory |
DOM |
The SunPCSC Provider
The SunPCSC provider enables applications to use the Java Smart Card I/O API to interact with the PC/SC Smart Card stack of the underlying operating system. Consult your operating system documentation for details.
On Linux, SunPCSC accesses the PC/SC stack via the
libpcsclite.so
library. It looks for this library in the
directories /usr/$LIBISA
and /usr/local/$LIBISA
,
where $LIBISA
is expanded to lib64
on 64-bit
Linux. The system property sun.security.smartcardio.library
may
also be set to the full filename of an alternate libpcsclite.so
implementation. On Windows, SunPCSC always calls into winscard.dll
and no Java-level configuration is necessary or possible.
If PC/SC is available on the host platform, the SunPCSC implementation
can be obtained via TerminalFactory.getDefault()
and
TerminalFactory.getInstance("PC/SC")
. If PC/SC is not available
or not correctly configured, a getInstance()
call will fail with a
NoSuchAlgorithmException
and getDefault()
will
return a JDK built-in implementation that does not support any terminals.
Algorithms
The following algorithms are available in the SunPCSC
provider:
Table 4-23 The SunPCSC Provider Algorithm Names for Engine Classes
Engine | Algorithm Names |
---|---|
TerminalFactory |
PC/SC |
The SunMSCAPI Provider
The SunMSCAPI
provider enables applications to use the
standard JCA/JCE APIs to access the native cryptographic libraries, certificates stores and
key containers on Windows. The SunMSCAPI
provider itself does not contain
cryptographic functionality, it is simply a conduit between the Java environment and the
native cryptographic services on Windows.
Algorithms
The following algorithms are available in the SunMSCAPI
provider:
Table 4-24 The SunMSCAPI Algorithm Names for Engine Classes
Engine | Algorithm Names |
---|---|
Cipher |
RSA RSA/ECB/PKCS1Padding only |
KeyPairGenerator |
RSA |
KeyStore |
Windows-MY-CURRENTUSER (also known as Windows-MY): The keystore type that identifies the native Microsoft Windows MY keystore. It contains the user's personal certificates and associated private keys that are only accessible to the current user account. Windows-ROOT-CURRENTUSER (also known as Windows-ROOT): The keystore type that identifies the native Microsoft Windows ROOT keystore. It contains the certificates of Root certificate authorities and other self-signed trusted certificates that are only accessible to the current user account. Windows-MY-LOCALMACHINE: The keystore type that identifies the native Microsoft Windows MY keystore. It contains certificates and associated private keys that are accessible to all accounts on the system. Windows-ROOT-LOCALMACHINE: The keystore type that identifies the native Microsoft Windows ROOT keystore. It contains the certificates of Root certificate authorities and other self-signed trusted certificates that are accessible to all accounts on the system. |
SecureRandom |
Windows-PRNG : The name of the native pseudo-random number generation (PRNG) algorithm. |
Signature |
MD5withRSA MD2withRSA NONEwithRSA SHA1withRSA SHA256withRSA SHA384withRSA SHA512withRSA RSASSA-PSS SHA1withECDSA SHA224withECDSA SHA256withECDSA SHA384withECDSA SHA512withECDSA |
Keysize Restrictions
The SunMSCAPI provider uses the following default keysizes (in bits) and enforce the following restrictions:
KeyGenerator
Table 4-25 The SunMSCAPI Provider Keysize Restrictions
Alg. Name | Default Keysize | Restrictions/Comments |
---|---|---|
RSA | 2048 | Keysize ranges from 512 bits to 16,384 bits (depending on the underlying Microsoft Windows cryptographic service provider). |
The SunEC Provider
The SunEC
provider implements Elliptical Curve
Cryptography (ECC). Compared to traditional cryptosystems such as RSA, ECC offers equivalent
security with smaller key sizes, which results in faster computations, lower power
consumption, and memory and bandwidth savings. Applications can use the standard JCA/JCE
APIs to access ECC functionality without the dependency on external ECC libraries (through
SunPKCS11
).
Algorithms
The following algorithms are available in the SunEC
provider:
Table 4-26 The SunEC Provider Names for Engine Classes
Engine | Algorithm Name(s) |
---|---|
AlgorithmParameters |
EC |
KeyAgreement |
ECDH, X25519, X448, XDH |
KeyFactory |
EC Ed25519 Ed448 EdDSA X25519 X448 XDH |
KeyPairGenerator |
EC Ed25519 Ed448 EdDSA X25519 X448 XDH |
Signature |
Ed25519 Ed448 EdDSA NONEwithECDSA SHA1withECDSA SHA224withECDSA SHA256withECDSA SHA384withECDSA SHA512withECDSA NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format SHA3-224withECDSA SHA3-256withECDSA SHA3-384withECDSA SHA3-512withECDSA SHA3-224withECDSAinP1363Format SHA3-256withECDSAinP1363Format SHA3-384withECDSAinP1363Format SHA3-512withECDSAinP1363Format |
Note:
- The EdDSA algorithm can be initialized with either Ed25519 or
Ed448 parameters and keys. If you initialize the EdDSA algorithm without any
parameters or keys, then by default it uses Ed25519 parameters and keys.
- All EdDSA variants — pure, prehashed, and context — are supported.
- The XDH algorithm can be initialized with either X25519 or X448 parameters and keys.
Keysize Restrictions
The SunEC provider uses the following default keysizes (in bits) and enforces the following restrictions:
Table 4-27 The SunEC Provider Keysize Restrictions
KeyPairGenerator Algorithm Name | Default Keysize | Restrictions/Comments |
---|---|---|
EC | 384 | Keysize must be 256, 384, or 521 |
Ed25519 | 255 | Keysize must be 255 |
Ed448 | 448 | Keysize must be 448 |
EdDSA | 255 | Keysize must be 255 or 448 |
X25519 | 255 | Keysize must be 255 |
X448 | 448 | Keysize must be 448 |
XDH | 255 | Keysize must be 255 or 448 |
Supported Elliptic Curve Names
The SunEC
provider includes implementations of various
elliptic curves for use with the EC, Elliptic-Curve Diffie-Hellman (ECDH), and
Elliptic Curve Digital Signature Algorithm (ECDSA) algorithms. Some of these curves
have been implemented using modern formulas and techniques that are valuable for
preventing side-channel attacks. The others are legacy curves that might be more
vulnerable to attacks and should not be used. The following tables list the curves
that fall into each of these categories.
In the following tables, the first column, Curve Name, lists the name
that SunEC
implements. The second column, Object Identifier,
specifies the EC name's object identifier. The third column, Additional
Names/Aliases, specifies any additional names or aliases for that curve. (A value of
N/A means that there are no additional names.) All strings that appear in one row
refer to the same curve. For example, the strings secp256r1
,
1.2.840.10045.3.1.7
, NIST P-256
, and
X9.62 prime256v1
refer to the same curve. You can use the curve
names to create parameter specifications for EC parameter generation with the ECGenParameterSpec class or the NamedParameterSpec class.
Recommended Curves
The following table lists the elliptic curves that are provided by the
SunEC
provider and are implemented using modern formulas and
techniques.
Table 4-28 Recommended Curves Provided by the SunEC Provider
Curve Name | Object Identifier | Additional Names/Aliases |
---|---|---|
Ed25519 | 1.3.101.112 | N/A |
Ed448 | 1.3.101.113 | N/A |
secp256r1 | 1.2.840.10045.3.1.7 | NIST P-256, X9.62 prime256v1 |
secp384r1 | 1.3.132.0.34 | NIST P-384 |
secp521r1 | 1.3.132.0.35 | NIST P-521 |
X25519 | 1.3.101.110 | N/A |
X448 | 1.3.101.111 | N/A |
Object Identifiers Associated with ECDSA Signatures
The following table lists object identifiers (OIDs) associated with ECDSA Signatures:
Table 4-29 OIDs associated with ECDSA Signatures
ECDSA Signature | OID |
---|---|
SHA1withECDSA | 1.2.840.10045.4.1 |
SHA224withECDSA | 1.2.840.10045.4.3.1 |
SHA256withECDSA | 1.2.840.10045.4.3.2 |
SHA384withECDSA | 1.2.840.10045.4.3.3 |
SHA512withECDSA | 1.2.840.10045.4.3.4 |
SHA3-224withECDSA | 2.16.840.1.101.3.4.3.9 |
SHA3-256withECDSA | 2.16.840.1.101.3.4.3.10 |
SHA3-384withECDSA | 2.16.840.1.101.3.4.3.11 |
SHA3-512withECDSA | 2.16.840.1.101.3.4.3.12 |
The Apple Provider
The Apple
provider implements a java.security.KeyStore
that provides access to the macOS Keychain.
Algorithms
The following algorithms are available in the Apple
provider:
Table 4-30 The Apple Provider Algorithm Name for Engine Classes
Engine | Algorithm Name(s) |
---|---|
KeyStore |
KeychainStore |