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 |
SunPKCS11Footref 1 |
|
jdk.crypto.ec |
SunECFootref 1 |
|
jdk.crypto.mscapi |
SunMSCAPIFootref 1 |
|
jdk.crypto.ucrypto |
OracleUcryptoFootref 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 works well for single blocks of data and can be parallelized, but absolutely should not be used for multiple blocks of data.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 |
|---|---|---|
| Solaris | 1. PKCS11Foot 2Foot 3 | SunPKCS11 |
| 2. NativePRNGFoot 4 | SUN | |
| 3. DRBG | SUN | |
| 4. SHA1PRNGFootref 4 | SUN | |
| 5. NativePRNGBlocking | SUN | |
| 6. NativePRNGNonBlocking | SUN | |
| Linux | 1. NativePRNGFootref 4 | SUN |
| 2. DRBG | SUN | |
| 3. SHA1PRNGFootref 4 | SUN | |
| 4. NativePRNGBlocking | SUN | |
| 5. NativePRNGNonBlocking | SUN | |
| macOS | 1. NativePRNGFootref 4 | SUN |
| 2. DRBG | SUN | |
| 3. SHA1PRNGFootref 4 | SUN | |
| 4. NativePRNGBlocking | SUN | |
| 5. NativePRNGNonBlocking | SUN | |
| Windows | 1. DRBG | SUN |
| 2. SHA1PRNG | SUN | |
| 3. Windows-PRNGFoot 5 | SunMSCAPI |
Footnote 2 The SunPKCS11 provider is available on all platforms, but is only enabled by default on Solaris as it is the only OS with a native PKCS11 implementation automatically installed and configured. On other platforms, applications or deployers must specifically install and configure a native PKCS11 library, and then configure and enable the SunPKCS11 provider to use it.
Footnote 3 The PKCS11 SecureRandom implementation for Solaris has been disabled due to the performance overhead of small-sized requests (see JDK-8098581: SecureRandom.nextBytes() hurts performance with small size requests). Edit sunpkcs11-solaris.cfg to reenable.
Footnote 4 On Solaris, Linux, and OS X, 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 5 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
JDK 1.1 introduced the Provider architecture. The first JDK provider was named SUN, and contained two types of cryptographic services (MessageDigestand Signature). In later releases, other mechanisms were added (SecureRandom, KeyPairGenerator, KeyFactory, and so on).
United States export regulations in effect at the time placed significant restrictions on the type of cryptographic functionality that could be made available internationally in the JDK. For this reason, the SUN provider has historically contained cryptographic engines that did not directly encrypt or decrypt data.
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 |
KeyPairGenerator |
DSA |
KeyStore |
PKCS12Foot 6 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 |
NONEwithDSA SHA1withDSA SHA224withDSA SHA256withDSA NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format |
Footnote 6 The PKCS12 KeyStore implementation does not support the KeyBag type.
The following table lists 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 |
Keysize Restrictions
The SUN provider uses the following default keysizes (in bits) and enforces the following restrictions:
KeyPairGenerator
| Alg. Name | Default Keysize | Restrictions/Comments |
|---|---|---|
| DSA | 2048 | Keysize must be a multiple of 64, ranging from 512 to 1024, plus 2048 and 3072. |
AlgorithmParameterGenerator
| Alg. 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
Additional details on the SUN provider implementations for CertificateFactory, CertPathBuilder, CertPathValidator and CertStore are documented in Appendix B: CertPath Implementation in SUN Provider of the PKI Programmer's Guide.
The SunRsaSign Provider
The SunRsaSign provider was introduced in JDK 1.3 as an enhanced replacement for the RSA signature in the SunJSSE provider.
The following algorithms are available in the SunRsaSign provider:
Table 4-7 The 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 RSASSA-PSS SHA1withRSAandMGF1 SHA224withRSAandMGF1 SHA256withRSAandMGF1 SHA384withRSAandMGF1 SHA512withRSAandMGF1 SHA512/224withRSAandMGF1 SHA512/256withRSAandMGF1 |
Keysize Restrictions
The SunRsaSign provider uses the following default keysize (in bits) and enforces the following restriction:
KeyPairGenerator
Table 4-8 The SunRsaSign Provider Keysize Restrictions
| Alg. Name | Default Keysize | Restrictions/Comments |
|---|---|---|
| RSA and RSASSA-PSS | 2048 | 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 Java Secure Socket Extension (JSSE) was originally released as a separate "Optional Package" (also briefly known as a "Standard Extension"), and was available for JDK 1.2.n and 1.3.n. The SunJSSE provider was introduced as part of this release.
In earlier JDK releases, there were no RSA signature providers available in the JDK, therefore SunJSSE had to provide its own RSA implementation in order to use commonly available RSA-based certificates. JDK 5 introduced the SunRsaSign provider, which provides all the functionality (and more) of the SunJSSE provider. Applications targeted at JDK 5.0 and later should request instances of the SunRsaSign provider instead. For backward compatibility, the RSA algorithms are still available through this provider, but are actually implemented in the SunRsaSign provider.
The following algorithms are available in the SunJSSE provider:
| Engine | Algorithm Name(s) |
|---|---|
KeyFactory |
RSA Note: The SunJSSE provider is for backwards compatibility with older releases, and should no longer be used for |
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. |
KeyPairGenerator |
RSA Note: The SunJSSE provider is for backwards compatibility with older releases, and should no longer be used for |
KeyStore |
PKCS12 Note: The SunJSSE provider is for backwards compatibility with older releases, and should no longer be used for |
Signature |
MD2withRSA MD5withRSA SHA1withRSA Note: The SunJSSE provider is for backwards compatibility with older releases, and should no longer be used for |
SSLContext |
SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3 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 following protocol parameters:
Table 4-9 SunJSSE Provider Protocol Parameters
| Protocol | Enabled by Default for Client | Enabled by Default for Server |
|---|---|---|
| SSLv3 | No (UnavailableFoot 7 ) | No (UnavailableFootref 7) |
| TLSv1 | Yes | Yes |
| TLSv1.1 | Yes | Yes |
| TLSv1.2 | Yes | Yes |
| TLSv1.3 | Yes | Yes |
| SSLv2HelloFoot 8 | No | Yes |
| DTLSv1.0 | Yes | Yes |
| DTLSv1.2Foot 9 | Yes | Yes |
Footnote 7 SSLv3 is enabled:
-
Starting with JDK 8u31, the SSLv3 protocol (Secure Socket Layer) has been deactivated and is not available by default. See the
java.security.SecurityPropertyjdk.tls.disabledAlgorithmsin the<java_home>/conf/security/java.securityfile. -
If SSLv3 is absolutely required, the protocol can be reactivated by removing "SSLv3" from the
jdk.tls.disabledAlgorithmsproperty in thejava.securityfile or by dynamically setting this Security Property before JSSE is initialized.
Footnote 8 The SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols allow you to send SSLv3, TLSv1, TLSv1.1 and TLSv1.2 ClientHello messages encapsulated in an SSLv2 format hello by using the SSLv2Hello psuedo-protocol.
Footnote 9 Both DTLSv1.0 and DTLSv1.2 are enabled.
The following table illustrates which connection combinations are possible when using SSLv2Hellos:
Table 4-10 Connections Possible Using SSLv2Hellos
| Client | Server | Connection Possible? |
|---|---|---|
| Enabled | Enabled | Yes |
| Not enabled | Enabled | Yes (most interoperable: SunJSSE default) |
| Enabled | Not enabled | No |
| Not enabled | Not enabled | 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.disabledAlgorithmsSecurity 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 Cipher Suites Available by Default
To determine the current list of cipher suites available by default, run the
following application, AvailableCipherSuites.java:
import java.util.*;
import java.security.*;
import javax.net.ssl.*;
public class AvailableCipherSuites {
public static void main(String[] args) throws Exception {
// If an argument is present, then remove the
// jdk.tls.disabledAlgorithms restrictions and
// print all implemented cipher suites.
if (args.length != 0) {
Security.setProperty("jdk.tls.disabledAlgorithms", "");
}
SSLContext sslc = SSLContext.getDefault();
SSLSocketFactory sslf = sslc.getSocketFactory();
SSLSocket ssls = (SSLSocket) sslf.createSocket();
ArrayList<String> enabled = new ArrayList(
Arrays.asList(ssls.getEnabledCipherSuites()));
ArrayList<String> supported = new ArrayList(
Arrays.asList(ssls.getSupportedCipherSuites()));
supported.removeAll(enabled);
System.out.println("Enabled by Default Cipher Suites");
System.out.println("--------------------------------");
enabled.stream().forEach(System.out::println);
System.out.println();
System.out.println("Not Enabled by Default Cipher Suites");
System.out.println("------------------------------------");
supported.stream().forEach(System.out::println);
}
}Without arguments, this application calls the methods SSLSocket.getSupportedCipherSuites() and SSLSocket.getEnabledCipherSuites() to print the available
enabled and supported cipher suites that are not disabled by the
jdk.tls.disabledAlgorithms Security Property. Running this
application with an argument removes the "Disabled by Security Property"
restriction; as a result, the application prints all possible cipher
suites.
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:
Table 4-11 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 PBEWithHmacSHA1AndAES_256 PBEWithHmacSHA224AndAES_256 PBEWithHmacSHA256AndAES_256 PBEWithHmacSHA384AndAES_256 PBEWithHmacSHA512AndAES_256 PBEWithMD5AndDES PBEWithMD5AndTripleDES PBEWithSHA1AndDESede PBEWithSHA1AndRC2_40 PBEWithSHA1AndRC2_128 PBEWithSHA1AndRC4_40 PBEWithSHA1AndRC4_128 RC2 |
Cipher |
See Table 4-12 |
KeyAgreement |
DiffieHellman |
KeyFactory |
DiffieHellman |
KeyGenerator |
AES ARCFOUR Blowfish ChaCha20 DES DESede HmacMD5 HmacSHA1 HmacSHA224 HmacSHA256 HmacSHA384 HmacSHA512 RC2 |
KeyPairGenerator |
DiffieHellman |
KeyStore |
JCEKS |
Mac |
HmacMD5 HmacSHA1 HmacSHA224 HmacSHA256 HmacSHA384 HmacSHA512 HmacSHA512/224 HmacSHA512/256 HmacPBESHA1 HmacPBESHA224 HmacPBESHA256 HmacPBESHA384 HmacPBESHA512 HmacPBESHA512/224 HmacPBESHA512/256 PBEWithHmacSHA1 PBEWithHmacSHA224 PBEWithHmacSHA256 PBEWithHmacSHA384 PBEWithHmacSHA512 |
SecretKeyFactory |
DES DESede PBEWithMD5AndDES PBEWithMD5AndTripleDES PBEWithSHA1AndDESede PBEWithSHA1AndRC2_40 PBEWithSHA1AndRC2_128 PBEWithSHA1AndRC4_40 PBEWithSHA1AndRC4_128 PBKDF2WithHmacSHA1 PBKDF2WithHmacSHA224 PBKDF2WithHmacSHA256 PBKDF2WithHmacSHA384 PBKDF2WithHmacSHA512 PBEWithHmacSHA1AndAES_128 PBEWithHmacSHA224AndAES_128 PBEWithHmacSHA256AndAES_128 PBEWithHmacSHA384AndAES_128 PBEWithHmacSHA512AndAES_128 PBEWithHmacSHA1AndAES_256 PBEWithHmacSHA224AndAES_256 PBEWithHmacSHA256AndAES_256 PBEWithHmacSHA384AndAES_256 PBEWithHmacSHA512AndAES_256 |
The following table lists cipher transformations available in the SunJCE provider.
Table 4-12 The SunJCE Provider Cipher Transformations
| Algorithm Names | Modes | Paddings |
|---|---|---|
| AES | ECB, CBC, PCBC, CFBFoot 10, CFB8..CFB128, OFBFootref 10, OFB8..OFB128 | NoPadding, PKCS5Padding, ISO10126Padding |
| 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, CFBFootref 10, CFB8..CFB64, OFBFootref 10, OFB8..OFB64 | NoPadding, PKCS5Padding, ISO10126Padding |
| ChaCha20 | None | NoPadding |
| ChaCha20-Poly1305 | None | NoPadding |
| DESedeWrap | CBC | NoPadding |
|
PBEWithMD5AndDES, PBEWithMD5AndTripleDESFoot 11, PBEWithSHA1AndDESede, PBEWithSHA1AndRC2_40, PBEWithSHA1AndRC2_128, PBEWithSHA1AndRC4_40, PBEWithSHA1AndRC4_128, PBEWithHmacSHA1AndAES_128, PBEWithHmacSHA224AndAES_128, PBEWithHmacSHA256AndAES_128, PBEWithHmacSHA384AndAES_128, PBEWithHmacSHA512AndAES_128, PBEWithHmacSHA1AndAES_256, PBEWithHmacSHA224AndAES_256, PBEWithHmacSHA256AndAES_256, PBEWithHmacSHA384AndAES_256, PBEWithHmacSHA512AndAES_256 |
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/2256ndMGF1Padding |
Footnote 10 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 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-13 The SunJCE Provider Key Size Restrictions
| Algorithm Name | Default Key size | Restrictions/Comments |
|---|---|---|
| AES | 128 | 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-14 KeyPairGenerator
| Algorithm Name | Default Key size | Restrictions/Comments |
|---|---|---|
| Diffie-Hellman (DH) | 2048 | Key size must be a multiple of 64, ranging from 512 to 1024, plus 1536, 2048, 3072, 4096, 6144, 8192. |
Table 4-15 AlgorithmParameterGenerator
| Algorithm Name | Default Key size | Restrictions/Comments |
|---|---|---|
| Diffie-Hellman (DH) | 2048 | Key size must be a multiple of 64, ranging from 512 to 1024, plus 2048 and 3072. |
The SunJGSS Provider
The following algorithms are available in the SunJGSS provider:
Table 4-16 The SunJGSS Provider
| OID | Name |
|---|---|
1.2.840.113554.1.2.2 |
Kerberos v5 |
1.3.6.1.5.5.2 |
SPNEGO |
The SunSASL Provider
The following algorithms are available in the SunSASL provider:
Table 4-17 The 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
The following algorithms are available in the XMLDSig provider:
Table 4-18 The XMLDSig Provider Algorithm Names for Engine Classes
| Engine | Algorithm Names |
|---|---|
KeyInfoFactory |
DOM |
TransformService |
http://www.w3.org/TR/2001/REC-xml-c14n-20010315 - (CanonicalizationMethod.INCLUSIVE) http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments - (CanonicalizationMethod.INCLUSIVE_WITH_COMMENTS) http://www.w3.org/2001/10/xml-exc-c14n# - (CanonicalizationMethod.EXCLUSIVE) http://www.w3.org/2001/10/xml-exc-c14n#WithComments - (CanonicalizationMethod.EXCLUSIVE_WITH_COMMENTS) http://www.w3.org/2000/09/xmldsig#base64 - (Transform.BASE64) http://www.w3.org/2000/09/xmldsig#enveloped-signature - (Transform.ENVELOPED) http://www.w3.org/TR/1999/REC-xpath-19991116 - (Transform.XPATH) http://www.w3.org/2002/06/xmldsig-filter2 - (Transform.XPATH2) http://www.w3.org/TR/1999/REC-xslt-19991116 - (Transform.XSLT) |
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 Solaris and Linux platforms, 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 lib/64 on 64-bit Solaris platforms and lib64 on 64-bit Linux platforms. The system property sun.security.smartcardio.library may also be set to the full filename of an alternate libpcsclite.so implementation. On Windows platforms, 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 JRE built-in implementation that does not support any terminals.
The following algorithms are available in the SunPCSC provider:
Table 4-19 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 the Microsoft Windows platform. 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.
The following algorithms are available in the SunMSCAPI provider:
Table 4-20 The SunMSCAPI Algorithm Names for Engine Classes
| Engine | Algorithm Names |
|---|---|
Cipher |
RSA RSA/ECB/PKCS1Padding only |
KeyPairGenerator |
RSA |
KeyStore |
Windows-MY : The keystore type that identifies the native Microsoft Windows MY keystore. It contains the user's personal certificates and associated private keys. 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. |
SecureRandom |
Windows-PRNG : The name of the native pseudo-random number generation (PRNG) algorithm. |
Signature |
MD5withRSA MD2withRSA NONEwithRSA SHA1withRSA SHA256withRSA SHA384withRSA SHA512withRSA RSASSA-PSS |
Keysize Restrictions
The SunMSCAPI provider uses the following default keysizes (in bits) and enforce the following restrictions:
KeyGenerator
Table 4-21 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 now use the standard JCA/JCE APIs to access ECC functionality without the dependency on external ECC libraries (via SunPKCS11), as was the case in the JDK 6 release.
The following algorithms are available in the SunEC provider:
Table 4-22 The SunEC Provider Names for Engine Classes
| Engine | Algorithm Name(s) |
|---|---|
AlgorithmParameters |
EC |
KeyAgreement |
ECDH, X25519, X448, XDH |
KeyFactory |
EC, X25519, X448, XDH |
KeyPairGenerator |
EC, X25519, X448, XDH |
Signature |
NONEwithECDSA SHA1withECDSA SHA224withECDSA SHA256withECDSA SHA384withECDSA SHA512withECDSA NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format |
Note:
-
The XDH algorithm can be initialized with either X25519 or X448 parameters and keys.
-
The X25519 algorithm supports X25519 parameters and keys only. Similarly, the X448 algorithm supports X448 parameters and keys only.
Keysize Restrictions
The SunEC provider uses the following default keysizes (in bits) and enforces the following restrictions:
KeyPairGenerator
Table 4-23 The SunEC Provider Keysize Restrictions
| Alg. Name | Default Keysize | Restrictions/Comments |
|---|---|---|
| EC | 256 | Keysize must range from 112 to 571 (inclusive). |
| X25519 | 255 | Keysize must be 255 |
| X448 | 448 | Keysize must be 448 |
| XDH | 255 | Keysize must be 255 or 448 |
Supported Elliptic Curve Names
Table 4-24 lists the elliptic curve (EC) names that SunEC
supports for the EC, Elliptic-Curve Diffie-Hellman (ECDH), and Elliptic Curve
Digital Signature Algorithm (ECDSA) algorithms. The first column lists all the
SunEC supported EC names. The second column specifies the EC
name's object identifier. The third column specifies any additional
SunEC supported EC names. (A value of N/A means that there are
no additional names.) All strings that appear in one row refer to the same EC. For
example, the strings secp256r1,
1.2.840.10045.3.1.7, NIST P-256, and
X9.62 prime256v1 refer to the same EC.
You can use EC names for the following:
- Creating a parameter specification for EC parameter generation with the ECGenParameterSpec class
- Generating a key pair with the
keytooltool: For example, the following command creates a EC key pair with the secp256r1 curve:keytool -genkeypair -keyalg EC -groupname secp256r1
Table 4-24 SunEC Supported EC Names
| Supported Name | Object Identifier | Additional Supported Names |
|---|---|---|
| brainpoolP256r1 | 1.3.36.3.3.2.8.1.1.7 | N/A |
| brainpoolP320r1 | 1.3.36.3.3.2.8.1.1.9 | N/A |
| brainpoolP384r1 | 1.3.36.3.3.2.8.1.1.11 | N/A |
| brainpoolP512r1 | 1.3.36.3.3.2.8.1.1.13 | N/A |
| secp112r1 | 1.3.132.0.6 | N/A |
| secp112r2 | 1.3.132.0.7 | N/A |
| secp128r1 | 1.3.132.0.28 | N/A |
| secp128r2 | 1.3.132.0.29 | N/A |
| secp160k1 | 1.3.132.0.9 | N/A |
| secp160r1 | 1.3.132.0.8 | N/A |
| secp160r2 | 1.3.132.0.30 | N/A |
| secp192k1 | 1.3.132.0.31 | N/A |
| secp192r1 | 1.2.840.10045.3.1.1 | NIST P-192, X9.62 prime192v1 |
| secp224k1 | 1.3.132.0.32 | N/A |
| secp224r1 | 1.3.132.0.33 | NIST P-224 |
| secp256k1 | 1.3.132.0.10 | 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 |
| sect113r1 | 1.3.132.0.4 | N/A |
| sect113r2 | 1.3.132.0.5 | N/A |
| sect131r1 | 1.3.132.0.22 | N/A |
| sect131r2 | 1.3.132.0.23 | N/A |
| sect163k1 | 1.3.132.0.1 | NIST K-163 |
| sect163r1 | 1.3.132.0.2 | N/A |
| sect163r2 | 1.3.132.0.15 | NIST B-163 |
| sect193r1 | 1.3.132.0.24 | N/A |
| sect193r2 | 1.3.132.0.25 | N/A |
| sect233k1 | 1.3.132.0.26 | NIST K-233 |
| sect233r1 | 1.3.132.0.27 | NIST B-233 |
| sect239k1 | 1.3.132.0.3 | N/A |
| sect283k1 | 1.3.132.0.16 | NIST K-283 |
| sect283r1 | 1.3.132.0.17 | NIST B-283 |
| sect409k1 | 1.3.132.0.36 | NIST K-409 |
| sect409r1 | 1.3.132.0.37 | NIST B-409 |
| sect571k1 | 1.3.132.0.38 | NIST K-571 |
| sect571r1 | 1.3.132.0.39 | NIST B-571 |
| X9.62 c2tnb191v1 | 1.2.840.10045.3.0.5 | N/A |
| X9.62 c2tnb191v2 | 1.2.840.10045.3.0.6 | N/A |
| X9.62 c2tnb191v3 | 1.2.840.10045.3.0.7 | N/A |
| X9.62 c2tnb239v1 | 1.2.840.10045.3.0.11 | N/A |
| X9.62 c2tnb239v2 | 1.2.840.10045.3.0.12 | N/A |
| X9.62 c2tnb239v3 | 1.2.840.10045.3.0.13 | N/A |
| X9.62 c2tnb359v1 | 1.2.840.10045.3.0.18 | N/A |
| X9.62 c2tnb431r1 | 1.2.840.10045.3.0.20 | N/A |
| X9.62 prime192v2 | 1.2.840.10045.3.1.2 | N/A |
| X9.62 prime192v3 | 1.2.840.10045.3.1.3 | N/A |
| X9.62 prime239v1 | 1.2.840.10045.3.1.4 | N/A |
| X9.62 prime239v2 | 1.2.840.10045.3.1.5 | N/A |
| X9.62 prime239v3 | 1.2.840.10045.3.1.6 | N/A |
The OracleUcrypto Provider
The Solaris-only security provider OracleUcrypto leverages the Solaris Ucrypto library to offload and delegate cryptographic operations supported by the Oracle SPARC T4 based on-core cryptographic instructions. The OracleUcrypto provider itself does not contain cryptographic functionality; it is simply a conduit between the Java environment and the Solaris Ucrypto library.
If the underlying Solaris Ucrypto library does not support a particular algorithm, then the OracleUcrypto provider will not support it either. Consequently, at runtime, the supported algorithms consists of the intersection of those that the Solaris Ucrypto library supports and those that the OracleUcrypto provider recognizes.
The following algorithms are available in the OracleUcrypto provider:
Table 4-25 The OracleUcrypto Provider Algorithm Names for Engine Classes
| Engine | Algorithm Name(s) |
|---|---|
Cipher |
AES RSA AES/ECB/NoPadding AES/ECB/PKCS5Padding AES/CBC/NoPadding AES/CBC/PKCS5Padding AES/CTR/NoPadding AES/GCM/NoPadding AES/CFB128/NoPadding AES/CFB128/PKCS5Padding AES_128/ECB/NoPadding AES_192/ECB/NoPadding AES_256/ECB/NoPadding AES_128/CBC/NoPadding AES_192/CBC/NoPadding AES_256/CBC/NoPadding AES_128/GCM/NoPadding AES_192/GCM/NoPadding AES_256/GCM/NoPadding RSA/ECB/PKCS1Padding RSA/ECB/NoPadding |
Signature |
MD5withRSA SHA1withRSA SHA256withRSA SHA384withRSA SHA512withRSA |
MessageDigest |
MD5 SHA SHA-224 SHA-256 SHA-384 SHA-512 SHA3–224 SHA3–256 SHA3–384 SHA3–512 |
Keysize Restrictions
The OracleUcrypto provider does not specify any default keysizes or keysize restrictions; these are specified by the underlying Solaris Ucrypto library.
OracleUcrypto Provider Configuration File
OracleUcrypto provider has a configuration file named ucrypto-solaris.cfg that resides in the $JAVA_HOME/conf/security directory. Modify this configuration file to specify which algorithms to disable by default. For example, the following configuration file disables AES with CFB128 mode by default:
#
# Configuration file for the OracleUcrypto provider
#
disabledServices = {
Cipher.AES/CFB128/PKCS5Padding
Cipher.AES/CFB128/NoPadding
}
The Apple Provider
The Apple provider implements a java.security.KeyStore that provides access to the macOS Keychain.
The following algorithms are available in the Apple provider:
Table 4-26 The Apple Provider Algorithm Name for Engine Classes
| Engine | Algorithm Name(s) |
|---|---|
KeyStore |
KeychainStore |
The JdkLDAP Provider
The JdkLDAP provider was introduced in JDK 9 as a replacement for the LDAP CertStore implementation in the SUN provider.
The following algorithms are available in the JdkLDAP provider:
Table 4-27 The JdkLDAP Provider Algorithm Names for Engine Classes
| Engine | Algorithm Names |
|---|---|
CertStore |
LDAP |