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:

^Footnote 1 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 2 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 3 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 4 There is currently no NativePRNG on Windows. Access to the equivalent functionality is via the SunMSCAPI 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.

Algorithms

The following algorithms are available in the SUN provider:

^Footnote 5 The PKCS12 KeyStore implementation does not support the KeyBag type.

OIDs Associated with SHA Message Digests and DSA Signatures

The following table lists OIDs associated with SHA Message Digests:

The following table lists OIDs associated with DSA Signatures:

Keysize Restrictions

The SUN provider uses the following default keysizes (in bits) and enforces the following restrictions:

CertificateFactory/CertPathBuilder/CertPathValidator/CertStore Implementations

See Appendix B: CertPath Implementation in SUN Provider in the Java PKI Programmer's Guide Additional for details of the SUN provider implementations for CertificateFactory, CertPathBuilder, CertPathValidator, and CertStore.

Algorithms

The following algorithms are available in the SunRsaSign provider:

Keysize Restrictions

The SunRsaSign provider uses the following default keysize (in bits) and enforces the following restriction:

Algorithms

The following algorithms are available in the SunJSSE provider:

SunJSSE Provider Protocol Parameters

The SunJSSE provider supports the protocol parameters listed in Table 4-12.

^Footnote 6 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.

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_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• 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_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

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 contains RC4, 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.

Alternatively, to obtain the current list of protocols and cipher suites that are available by default, run the following command:

java -XshowSettings:security:tls

Note that the list generated by these commands don'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.

Algorithms

The following algorithms are available in the SunJCE provider:

Cipher Transformations

The following table lists cipher transformations available in the SunJCE provider.

^Footnote 7 CFB/OFB with no specified value defaults to the block size of the algorithm. (for example, AES is 128; Blowfish, DES, DESede, and RC2 are 64.)

^Footnote 8 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 9 PBEWithMD5AndTripleDES is a proprietary algorithm that has not been standardized.

Keysize Restrictions

The SunJCE provider uses the following default keysizes (in bits) and enforces the following restrictions:

Algorithms

The following algorithms are available in the SunJGSS provider:

Algorithms

The following algorithms are available in the SunSASL provider:

Algorithms

The following algorithms are available in the XMLDSig 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, 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 and 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:

Algorithms

The following algorithms are available in the SunMSCAPI provider:

Keysize Restrictions

The SunMSCAPI provider uses the following default keysizes (in bits) and enforce the following restrictions:

KeyGenerator

Algorithms

The following algorithms are available in the SunEC provider:

^Footnote 10 This algorithm won't be available from the SunEC provider through the JCA/JCE APIs if you delete the SunEC provider's native library. See Effect of Removing SunEC Provider's Native Library.

Effect of Removing SunEC Provider's Native Library

The SunEC provider uses a native library to provide some ECC functionality. If you don't want to use this native library, then delete the following files (depending on your operating system):

• Linux: $JAVA_HOME/lib/libsunec.so
• macOS: $JAVA_HOME/lib/libsunec.dylib
• Windows: %JAVA_HOME%\bin\sunec.dll

If you delete the native library, then the algorithms with a footnote in Table 4-24 won't be available from the SunEC provider through the JCA/JCE APIs.

Libraries and tools (for example, JSSE, XML Digital Signature, and keytool) that use these algorithms may have reduced functionality. For example, JSSE may no longer be able to generate EC keypairs, use EC-based peer certificates, or perform ECDH/ECDHE key agreements for SSL/TLS/DTLS connections. Ciphersuites such as TLS_*_ECDSA and TLS_ECDHE_* may be unavailable. SSL/TLS connections can still use alternate algorithms to secure connections, such as RSA-/DSA-based certificates and key agreements based on DH/DHE (RFC 2631), FFDHE (RFC 7919), or XDH/x25519/x448 (RFC 7748).

Even if the native library is removed, the rest of the algorithms (the algorithms without a footnote) are still available from the SunEC provider, as they are not implemented in the native library code.

Keysize Restrictions

The SunEC provider uses the following default keysizes (in bits) and enforces the following restrictions:

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 for the curves X25519 and X448.

Recommended Curves

The following table lists the elliptic curves that are provided by the SunEC provider and are implemented using modern formulas and techniques. These curves are recommended and should be preferred over the curves listed in the section Legacy Curves Retained for Compatibility.

Legacy Curves Retained for Compatibility

The following table lists elliptic curves that are provided by the SunEC provider and are not implemented using modern formulas and techniques. These curves remain available for compatibility reasons to afford legacy systems time to migrate to newer curves. These implementations will be removed or replaced in a future version of the JDK.

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.

Algorithms

The following algorithms are available in the OracleUcrypto provider:

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

#
# Configuration file for the OracleUcrypto provider
#
disabledServices = {
  Cipher.AES/CFB128/PKCS5Padding
  Cipher.AES/CFB128/NoPadding
}

Algorithms

The following algorithms are available in the Apple provider:

Algorithms

The following algorithms are available in the JdkLDAP provider:

Algorithms

The following algorithms are available in the JdkSASL provider: