1. Security Developer’s Guide
  2. JDK Providers Documentation

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.

Topics

Introduction to JDK Providers

Import Limits on Cryptographic Algorithms

Cipher Transformations

SecureRandom Implementations

The SunPKCS11 Provider

The SUN Provider

The SunRsaSign Provider

The SunJSSE Provider

The SunJCE Provider

The SunJGSS Provider

The SunSASL Provider

The XMLDSig Provider

The SunPCSC Provider

The SunMSCAPI Provider

The SunEC Provider

The Apple Provider

The JdkLDAP Provider

The JdkSASL Provider

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
KeyPairGenerator DSA
KeyStore

PKCS12Foot 4

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 java.security entropy gathering device.)

NativePRNG

(nextBytes() uses /dev/urandom, generateSeed() uses /dev/random)

NativePRNGBlocking

(nextBytes() and generateSeed() use /dev/random)

NativePRNGNonBlocking

(nextBytes() and generateSeed() use /dev/urandom)

Signature

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

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

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:

Table 4-10 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 following algorithms are available in the SunJSSE provider:

Table 4-11 Algorithms in SunJSSE Provider

Engine Algorithm Name(s)
KeyManagerFactory

PKIX: A factory for X509ExtendedKeyManager instances that manage X.509 certificate-based key pairs for local side authentication according to the rules defined by the IETF PKIX working group in RFC 5280. This KeyManagerFactory currently supports initialization using a KeyStore object or javax.net.ssl.KeyStoreBuilderParameters.

SunX509: A factory for X509ExtendedKeyManager instances that manage X.509 certificate-based key pairs for local side authentication, but with less strict checking of certificate usage/validity and chain verification. This KeyManagerFactory supports initialization using a Keystore object, but does not currently support initialization using the class javax.net.ssl.ManagerFactoryParameters.

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

SSLContext

SSL

SSLv3

TLS

TLSv1

TLSv1.1

TLSv1.2

TLSv1.3

DTLS

DTLSv1.0

DTLSv1.2
TrustManagerFactory

PKIX: A factory for X509ExtendedTrustManager instances that validate certificate chains according to the rules defined by the IETF PKIX working group in RFC 5280. This TrustManagerFactory currently supports initialization using a KeyStore object or javax.net.ssl.CertPathTrustManagerParameters.

SunX509: A factory for X509ExtendedTrustManager instances that validate certificate chains, but with less strict checking of certificate usage/validity and chain verification. This TrustManagerFactory supports initialization using a Keystore object, but does not currently support initialization using the class javax.net.ssl.ManagerFactoryParameters.

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 5 Yes Yes
TLSv1.1Foot 5 Yes Yes
TLSv1.2 Yes Yes
TLSv1.3 Yes Yes
SSLv2Hello No No
DTLSv1.0 Yes Yes
DTLSv1.2 Yes Yes

Footnote 5 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 contains SSLv3, 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 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 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:

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

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-16
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
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-16 The SunJCE Provider Cipher Transformations

Algorithm Names Modes Paddings
AES ECB, CBC, PCBC, CFBFoot 6, CFB8..CFB128, OFBFoot 6, OFB8..OFB128 NoPadding, PKCS5Padding, ISO10126PaddingFoot 7
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 6, CFB8..CFB64, OFBFoot 6, OFB8..OFB64 NoPadding, PKCS5Padding, ISO10126Padding
ChaCha20 None NoPadding
ChaCha20-Poly1305 None NoPadding
DESedeWrap CBC NoPadding

PBEWithMD5AndDES, PBEWithMD5AndTripleDESFoot 8, 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 6 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 7 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 8 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
  • 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 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 256 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

The JdkLDAP Provider

The JdkLDAP provider replaces the LDAP CertStore implementation in the SUN provider.

Algorithms

The following algorithms are available in the JdkLDAP provider:

Table 4-31 The JdkLDAP Provider Algorithm Names for Engine Classes

Engine Algorithm Names
CertStore

LDAP

The JdkSASL Provider

Algorithms

The following algorithms are available in the JdkSASL provider:

Table 4-32 The JdkSASL Provider Algorithm Names for Engine Classes

Engine Algorithm Names
SaslClient

GSSAPI

SaslServer

GSSAPI