• Java Software
• Java SE Downloads
• Java SE 8 Documentation

Search

The following topics are covered:

• Introduction
• Import Limits on CryptographicAlgorithms
• Cipher Transformations
• SecureRandomImplementations
• TheSunPKCS11Provider
• TheSUN Provider
• TheSunRsaSignProvider
• TheSunJSSEProvider
• TheSunJCEProvider
• TheSunJGSSProvider
• TheSunSASLProvider
• TheXMLDSigProvider
• TheSunPCSCProvider
• TheSunMSCAPIProvider
• TheSunEC Provider
• TheOracleUcryptoProvider
• TheApple Provider

Note:Java Cryptography Architecture (JCA) Standard Algorithm Name Documentation for JDK 8 contains more information about the standardnames used in this document.

Introduction

The Java platform defines a set of APIs spanning major securityareas, including cryptography, public key infrastructure,authentication, secure communication, and access control. TheseAPIs allow developers to easily integrate security mechanisms intotheir application code. TheJavaCryptography Architecture (JCA) and itsProvider Architecture isa core concept of the Java Development Kit (JDK). It is assumedreaders have a solid understanding of this architecture.

This document describes the technical details of the providersshipped as part of Oracle's Java Environment.

Reminder: Cryptographic implementations in the JDK aredistributed through several different providers (SUN,SunJSSE,SunJCE,SunRsaSign) for bothhistorical reasons and by the types of services provided. General purposeapplicationsSHOULD NOT request cryptographic services fromspecific providers.That is:

getInstance("...","SunJCE");  // not recommended

versus

getInstance("...");            // recommended

Otherwise, applications are tied to specific providers that maynot be available on other Java implementations. They also might notbe able to take advantage of available optimized providers (forexample, hardware accelerators via PKCS11 or native OSimplementations such as Microsoft's MSCAPI) that have a higherpreference order than the specific requested provider.

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 thestrength of those algorithms. The JDK provides two different sets of jurisdictionpolicy files, "limited" and "unlimited", in the directory<java-home>/jre/lib/security/policythat determine the strength of cryptographic algorithms. Information aboutjurisdiction policy files and how to activate them is available inAppendix C: Cryptographic Strength Configuration.

Consult your export/import control counsel or attorney to determine the exactrequirements for your location.

For the "limited" configuration, the following table lists the maximum key sizesallowed by the "limited" set of jurisdiction policy files:

CipherTransformations

Thejavax.crypto.Cipher.getInstance(Stringtransformation) factory method generatesCiphers using transformations of the formalgorithm/mode/padding. If the mode/padding areomitted, theSunJCE andSunPKCS11 providers useECB as the default mode and PKCS5Padding as the default padding for manysymmetric ciphers.

It is recommended to use transformations that fully specify thealgorithm, mode, and padding instead of relying on thedefaults.

Note: ECB works well for single blocks of dataand can be parallelized, but absolutely should not be used formultiple blocks of data.

SecureRandomImplementations

The following table lists the default preference order of theavailableSecureRandom implementations.

* TheSunPKCS11 provider is available on all platforms, but isonly enabled by default on Solaris as it is the only OS with anative PKCS11 implementation automatically installed andconfigured. On other platforms, applications or deployers mustspecifically install and configure a native PKCS11 library, andthen configure and enable theSunPKCS11 provider to use it.

** On Solaris, Linux, and macOS, if theentropy gatheringdevice injava.security is set tofile:/dev/urandom orfile:/dev/random,then NativePRNG is preferred to SHA1PRNG. Otherwise, SHA1PRNG ispreferred.

*** There is currently no NativePRNG on Windows. Access to theequivalent functionality is via theSunMSCAPI provider.

If there are noSecureRandom implementationsregistered in the JCA framework,java.security.SecureRandom will use the hardcodedSHA1PRNG.

TheSunPKCS11 Provider

The Cryptographic Token Interface Standard (PKCS#11) provides nativeprogramming interfaces to cryptographic mechanisms, such ashardware cryptographic accelerators and Smart Cards. When properlyconfigured, theSunPKCS11 provider enablesapplications to use the standard JCA/JCE APIs to access nativePKCS#11 libraries.TheSunPKCS11 provider itselfdoes not contain cryptographic functionality, it is simply aconduit between the Java environment and the native PKCS11providers. TheJava PKCS#11 ReferenceGuide has a much more detailed treatment of this provider.

TheSUN Provider

JDK 1.1 introduced theProvider architecture. Thefirst JDK provider was namedSUN, and contained twotypes of cryptographic services (MessageDigests andSignatures). In later releases, other mechanisms wereadded (SecureRandom number generators,KeyPairGenerators,KeyFactorys, and soon.).

United States export regulations in effect at the time placedsignificant restrictions on the type of cryptographic functionalitythat could be made available internationally in the JDK. For thisreason, theSUN provider has historically containedcryptographic engines that did not directly encrypt or decryptdata.

The following algorithms are available in theSUNprovider:

The following table lists OIDs associated with SHA MessageDigests:

The following table lists OIDs associated with DSASignatures:

Keysize Restrictions

TheSUN provider uses the following defaultkeysizes (in bits) and enforces the following restrictions:

KeyPairGenerator

AlgorithmParameterGenerator

CertificateFactory/CertPathBuilder/CertPathValidator/CertStoreImplementations

Additional details on theSUN providerimplementations forCertificateFactory,CertPathBuilder,CertPathValidator andCertStore are documented inAppendix B of the PKIProgrammer's Guide.

TheSunRsaSign Provider

TheSunRsaSign provider was introduced in JDK 1.3as an enhanced replacement for the RSA signatures in theSunJSSE provider.

The following algorithms are available in theSunRsaSign provider:

Keysize Restrictions

TheSunRsaSign provider uses the following defaultkeysize (in bits) and enforces the following restriction:

KeyPairGenerator

TheSunJSSE Provider

The Java Secure Socket Extension (JSSE) was originally releasedas a separate "Optional Package" (also briefly known as a "StandardExtension"), and was available for JDK 1.2.n and1.3.n. TheSunJSSE provider was introduced aspart of this release.

In earlier JDK releases, there were no RSA signature providersavailable in the JDK, thereforeSunJSSE had to provideits own RSA implementation in order to use commonly availableRSA-based certificates. JDK 5 introduced theSunRsaSign provider, which provides all thefunctionality (and more) of theSunJSSE provider.Applications targeted at JDK 5.0 and later should request instancesof theSunRsaSign provider instead. For backwardcompatibility, the RSA algorithms are still available through thisprovider, but are actually implemented in theSunRsaSign provider.

Algorithms

The following algorithms are available in theSunJSSE provider:

Footnote 1 The PKCS12KeyStore implementation does not support theKeyBag type.

Protocols

The following table lists theprotocol parameters that theSunJSSE provider supports:

Footnote 1 -TLS 1.0 and 1.1 are versions of the TLS protocol that are no longerconsidered 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 youencounter issues, you can, at your own risk, re-enable the versions by removingTLSv1 or TLSv1.1 from thejdk.tls.disabledAlgorithms SecurityProperty in thejava.security configuration file.

Footnote 2 -The SSLv3, TLSv1, TLSv1.1 andTLSv1.2 protocols allow you to send SSLv3, TLSv1, TLSv1.1 andTLSv1.2 ClientHellos encapsulated in an SSLv2 format hello by usingthe SSLv2Hello pseudo-protocol. The following table illustrateswhich connection combinations are possible when usingSSLv2Hellos:

Note: The protocols available by default in a JDK releasechange as new protocols are developed and old protocols are found to be lesseffective than previously thought. The JDK uses two mechanisms to restrict theavailability of these protocols:

• Thejdk.tls.disabledAlgorithms Security Property: This disables categories of protocols and cipher suites. For example, if this Security Property containsSSLv3, then the SSLv3 protocol would be disabled. SeeDisabled 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 the previous table.

Cipher Suites

The following are the currently implemented SunJSSE cipher suites for thisJDK release, sorted by order of preference. Not all of these cipher suites areavailable for use by default.

• TLS_AES_256_GCM_SHA384
• TLS_AES_128_GCM_SHA256
• 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_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
• 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_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
• SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
• SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
• TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
• SSL_RSA_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
• TLS_KRB5_WITH_3DES_EDE_CBC_SHA
• TLS_KRB5_WITH_3DES_EDE_CBC_MD5
• TLS_KRB5_WITH_RC4_128_SHA
• TLS_KRB5_WITH_RC4_128_MD5
• TLS_KRB5_WITH_DES_CBC_SHA
• TLS_KRB5_WITH_DES_CBC_MD5
• TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
• TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
• TLS_KRB5_EXPORT_WITH_RC4_40_SHA
• TLS_KRB5_EXPORT_WITH_RC4_40_MD5

Tighter Checking ofEncryptedPreMasterSecret Version Numbers

Prior to the JDK 7 release, the SSL/TLS implementation did notcheck the version number in PreMasterSecret, and the SSL/TLS clientdid not send the correct version number by default. Unless thesystem propertycom.sun.net.ssl.rsaPreMasterSecretFixis set totrue, the TLS client sends the activenegotiated version, but not the expected maximum version supportedby the client.

For compatibility, this behavior is preserved for SSL version3.0 and TLS version 1.0. However, for TLS version 1.1 or later, theimplementation tightens checking the PreMasterSecret versionnumbers as required byRFC 5246. Clients alwayssend the correct version number, and servers check the versionnumber strictly. The system property,com.sun.net.ssl.rsaPreMasterSecretFix, is not used inTLS 1.1 or later.

TheSunJCE Provider

As described briefly inTheSUN Provider, US export regulations at the timerestricted the type of cryptographic functionality that could bemade available in the JDK. A separate API and referenceimplementation was developed that allowed applications toencrypt/decrypt data. The Java Cryptographic Extension (JCE) wasreleased as a separate "Optional Package" (also briefly known as a"Standard Extension"), and was available for JDK 1.2.x and 1.3.x.During the development of JDK 1.4, regulations were relaxed enoughthat JCE (and SunJSSE) could be bundled as part of the JDK.

The following algorithms are available in theSunJCEprovider:

The following table listscipher algorithms available in theSunJCE provider.

Footnote 1Though the standard doesn't specify or require the padding bytes to be random,the Java SE ISO10126Padding implementation pads with random bytes (until thelast byte, which provides the length of padding, as specified).

Footnote 2PBEWithMD5AndTripleDES is a proprietary algorithm that has not beenstandardized.

Keysize Restrictions

TheSunJCE provider uses the following default keysizes (inbits) and enforces the following restrictions:

KeyGenerator

Note: The various Password-Based Encryption (PBE)algorithms use various algorithms to generate key data, andultimately depends on the targeted Cipher algorithm. For example,"PBEWithMD5AndDES" will always generate 56-bit keys.

KeyPairGenerator

AlgorithmParameterGenerator

TheSunJGSS Provider

The following algorithms are available in theSunJGSS provider:

TheSunSASL Provider

The following algorithms are available in theSunSASL provider:

TheXMLDSig Provider

The following algorithms are available in theXMLDSig provider:

TheSunPCSC Provider

TheSunPCSC provider enables applications to use theJava Smart Card I/OAPI to interact with the PC/SC Smart Card stack of theunderlying operating system. On some operating systems, it may benecessary to enable and configure the PC/SC stack before it isusable. Consult your operating system documentation fordetails.

On Solaris and Linux platforms,SunPCSC accesses the PC/SC stackvia thelibpcsclite.so library. It looks for thislibrary in the directories/usr/$LIBISA and/usr/local/$LIBISA, where$LIBISA isexpanded tolib on 32-bit platforms,lib/64 on 64-bit Solaris platforms, andlib64 on 64-bit Linux platforms. The system propertysun.security.smartcardio.library may also be set tothe full filename of an alternatelibpcsclite.soimplementation. On Windows platforms,SunPCSC always calls intowinscard.dll and no Java-level configuration isnecessary or possible.

If PC/SC is available on the host platform, theSunPCSCimplementation can be obtained viaTerminalFactory.getDefault() andTerminalFactory.getInstance("PC/SC"). If PC/SC is notavailable or not correctly configured, agetInstance()call will fail with aNoSuchAlgorithmException andgetDefault() will return a JRE built-in implementationthat does not support any terminals.

The following algorithms are available in theSunPCSC provider:

TheSunMSCAPI Provider

TheSunMSCAPI provider enables applications to use the standardJCA/JCE APIs to access the native cryptographic libraries,certificates stores and key containers on the Microsoft Windowsplatform. TheSunMSCAPI provider itself does not containcryptographic functionality, it is simply a conduit between theJava environment and the native cryptographic services onWindows.

The following algorithms are available in theSunMSCAPI provider:

Keysize Restrictions

TheSunMSCAPI provider uses the following default keysizes (inbits) and enforce the following restrictions:

KeyGenerator

TheSunECProvider

TheSunEC provider implements Elliptical Curve Cryptography(ECC). Compared to traditional cryptosystems such as RSA, ECC offersequivalent security with smaller key sizes, which results in fastercomputations, lower power consumption, and memory and bandwidth savings.Applications can use the standard JCA/JCE APIs to access ECC functionalitywithout the dependency on external ECC libraries (throughSunPKCS11).

The following algorithms are available in theSunECprovider:

Footnote 1This algorithm won't be available from the SunEC provider through theJCA/JCE APIs if you delete theSunEC provider's native library.SeeEffect ofRemoving SunEC Provider's Native Library.

Effect ofRemoving SunEC Provider's Native Library

TheSunEC provider uses a native library to provide someECC functionality. If you don't want to use this native library, thendelete 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 footnotein the previous table won't be available from theSunECprovider through the JCA/JCE APIs.

Note: Other installed providers (for example,SunPCKS11) may still provide these algorithms.

Libraries and tools (for example, JSSE, XML Digital Signature, andkeytool) 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 forSSL/TLS connections. Ciphersuites such as TLS_*_ECDSA and TLS_ECDHE_* maybe unavailable. SSL/TLS connections can still use alternate algorithms tosecure connections, such as RSA-/DSA-based certificates and key agreementsbased on DH/DHE (RFC 2631) or FFDHE (RFC 7919).

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

Keysize Restrictions

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

KeyPairGenerator

Supported Elliptic Curve Names

TheSunEC provider includes implementations of variouselliptic curves for use with the EC, Elliptic-Curve Diffie-Hellman (ECDH),and Elliptic Curve Digital Signature Algorithm (ECDSA) algorithms. Some ofthese curves have been implemented using modern formulas and techniquesthat are valuable for preventing side-channel attacks. The others arelegacy curves that might be more vulnerable to attacks and should not beused. The tables below list the curves that fall into each of thesecategories.

In the following tables, the first column, Curve Name, lists the namethat SunEC implements. The second column, Object Identifier, specifies theEC name's object identifier. The third column, Additional Names/Aliases,specifies any additional names or aliases for that curve. All strings thatappear in one row refer to the same curve. For example, the stringssecp256r1,1.2.840.10045.3.1.7,NIST P-256, andX9.62 prime256v1 refer to the samecurve. You can use the curve names to create parameter specifications forEC parameter generation with theECGenParameterSpec class.

Recommended Curves

The following table lists the elliptic curves that are provided by theSunEC provider and are implemented using modern formulas andtechniques. These curves are recommended and should be preferred over thecurves listed in the sectionLegacy Curves Retained for Compatibility.

Legacy Curves Retained for Compatibility

It is recommended that you migrate to newer curves.

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

TheOracleUcrypto Provider

The Solaris-only security providerOracleUcryptoleverages the Solaris Ucrypto library to offload and delegatecryptographic operations supported by the Oracle SPARC T4 basedon-core cryptographic instructions. TheOracleUcryptoprovider itself does not contain cryptographic functionality; it issimply a conduit between the Java environment and the SolarisUcrypto library.

If the underlying Solaris Ucrypto library does not support aparticular algorithm, then theOracleUcrypto provider will notsupport it either. Consequently, at runtime, the supportedalgorithms consists of the intersection of those that the SolarisUcrypto library supports and those that theOracleUcrypto provider recognizes.

Note that theOracleUcrypto provider is includedonly in Oracle's JDK. It is not part of OpenJDK.

The following algorithms are available in theOracleUcrypto provider:

Keysize Restrictions

TheOracleUcrypto provider does not specify anydefault keysizes or keysize restrictions; these are specified bythe underlying Solaris Ucrypto library.

OracleUcrypto Provider Configuration File

TheOracleUcrypto provider has a configuration filenameducrypto-solaris.cfg that resides in the$JAVA_HOME/lib/security directory. Modify thisconfiguration file to specify which algorithms to disable bydefault. For example, the following configuration file disables AESwith CFB128 mode by default:

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

The Apple Provider

TheApple provider implements ajava.security.KeyStore that provides access to the macOS Keychain.

The following algorithms are available in theAppleprovider: