Java Cryptography Architecture Oracle Providers
Documentation (original) (raw)
The following topics are covered:
- Introduction
- Import Limits on Cryptographic Algorithms
- Cipher Transformations
- SecureRandom Implementations
- The SunPKCS11Provider
- The SUN Provider
- The SunRsaSignProvider
- The SunJSSEProvider
- The SunJCEProvider
- The SunJGSSProvider
- The SunSASLProvider
- The XMLDSigProvider
- The SunPCSCProvider
- The SunMSCAPIProvider
- The SunEC Provider
- The OracleUcryptoProvider
- The Apple Provider
Note: The Standard Names Documentation contains more information about the standard names used in this document.
Introduction
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 allow developers to easily integrate security mechanisms into their application code. The Java Cryptography Architecture (JCA) and its Provider Architecture is a core concept of the Java Development Kit (JDK). It is assumed readers have a solid understanding of this architecture.
This document describes the technical details of the providers shipped as part of Oracle's Java Environment.
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.
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, "limited" and "unlimited", in the directory_<java-home>_/jre/lib/security/policy
that determine the strength of cryptographic algorithms. Information about jurisdiction 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 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:
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 generatesCipher
s using transformations of the formalgorithm/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.
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.
OS | Algorithm Name | Provider Name |
---|---|---|
Solaris | 1. PKCS11* | SunPKCS11 |
2. NativePRNG** | Sun | |
3. SHA1PRNG** | Sun | |
4. NativePRNGBlocking | Sun | |
5. NativePRNGNonBlocking | Sun | |
Linux | 1. NativePRNG** | Sun |
2. SHA1PRNG** | Sun | |
3. NativePRNGBlocking | Sun | |
4. NativePRNGNonBlocking | Sun | |
macOS | 1. NativePRNG** | Sun |
2. SHA1PRNG** | Sun | |
3. NativePRNGBlocking | Sun | |
4. NativePRNGNonBlocking | Sun | |
Windows | 1. SHA1PRNG | Sun |
2. Windows-PRNG*** | SunMSCAPI |
* 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.
** On Solaris, Linux, and macOS, if the entropy gathering device in java.security
is set tofile:/dev/urandom
or file:/dev/random
, then NativePRNG is preferred to SHA1PRNG. Otherwise, SHA1PRNG is preferred.
*** There is currently no NativePRNG on Windows. Access to the equivalent functionality is via the SunMSCAPI
provider.
If there are no SecureRandom
implementations registered in the JCA framework,java.security.SecureRandom
will use the hardcoded SHA1PRNG.
TheSunPKCS11
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 Java 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 (MessageDigest
s andSignature
s). In later releases, other mechanisms were added (SecureRandom
number generators,KeyPairGenerator
s, KeyFactory
s, 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:
Engine | Algorithm Names |
---|---|
AlgorithmParameterGenerator | DSA |
AlgorithmParameters | DSA |
CertificateFactory | X.509 |
CertPathBuilder | PKIX |
CertPathValidator | PKIX |
CertStore | CollectionLDAP |
Configuration | JavaLoginConfig |
KeyFactory | DSA |
KeyPairGenerator | DSA |
KeyStore | JKSDKS |
MessageDigest | MD2MD5SHA-1SHA-224SHA-256SHA-384SHA-512SHA-512/224SHA-512/256 |
Policy | JavaPolicy |
SecureRandom | 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() andgenerateSeed() use /dev/random)NativePRNGNonBlocking (nextBytes() andgenerateSeed() use/dev/urandom) |
Signature | NONEwithDSASHA1withDSASHA224withDSASHA256withDSANote: 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." |
The following table lists 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 |
The following table lists OIDs associated with DSA Signatures:
DSA Signature | OID |
---|---|
SHA1withDSA | 1.2.840.10040.4.31.3.14.3.2.131.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 (inclusive), or 2048. |
AlgorithmParameterGenerator
Alg. Name | Default Keysize | Restrictions/Comments |
---|---|---|
DSA | 2048 | Keysize must be a multiple of 64, ranging from 512 to 1024 (inclusive), or 2048. |
CertificateFactory
/CertPathBuilder
/CertPathValidator
/CertStore
Implementations
Additional details on the SUN
provider implementations for CertificateFactory
,CertPathBuilder
, CertPathValidator
andCertStore
are documented in Appendix B of the PKI Programmer's Guide.
TheSunRsaSign
Provider
The SunRsaSign
provider was introduced in JDK 1.3 as an enhanced replacement for the RSA signatures in the SunJSSE provider.
The following algorithms are available in theSunRsaSign
provider:
Engine | Algorithm Names |
---|---|
AlgorithmParameters | RSASSA-PSS |
KeyFactory | RSARSASSA-PSS |
KeyPairGenerator | RSARSASSA-PSS |
Signature | MD2withRSAMD5withRSARSASSA-PSSSHA1withRSASHA224withRSASHA256withRSASHA384withRSASHA512withRSASHA512/224withRSASHA512/256withRSA |
Keysize Restrictions
The SunRsaSign
provider uses the following default keysize (in bits) and enforces the following restriction:
KeyPairGenerator
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. |
TheSunJSSE
Provider
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 theSunRsaSign
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 theSunRsaSign
provider.
Algorithms
The following algorithms are available in theSunJSSE
provider:
Engine | Algorithm Name(s) |
---|---|
KeyFactory | RSA |
KeyManagerFactory | SunX509: A factory for X509ExtendedKeyManagerinstances 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 3280 or its successor. This KeyManagerFactorysupports initialization using a Keystore object, but does not currently support initialization using the classjavax.net.ssl.ManagerFactoryParameters. PKIX: A factory for X509ExtendedKeyManagerinstances 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 3280 or its successor. This KeyManagerFactorycurrently supports initialization using a KeyStoreobject or javax.net.ssl.KeyStoreBuilderParameters. |
KeyPairGenerator | RSA |
KeyStore | PKCS12Footnote 1 |
Signature | MD2withRSAMD5withRSASHA1withRSA |
SSLContext | SSLv3TLSv1TLSv1.1TLSv1.2 |
TrustManagerFactory | SunX509: A factory for X509ExtendedTrustManagerinstances that validate certificate chains according to the rules defined by the IETF PKIX working group in RFC 3280 or its successor. This TrustManagerFactory supports initialization using a Keystore object, but does not currently support initialization using the classjavax.net.ssl.ManagerFactoryParameters. PKIX: A factory for X509ExtendedTrustManagerinstances that validate certificate chains according to the rules defined by the IETF PKIX working group in RFC 3280 or its successor. This TrustManagerFactory currently supports initialization using a KeyStore object orjavax.net.ssl.CertPathTrustManagerParameters. |
Footnote 1 The PKCS12 KeyStore
implementation does not support theKeyBag
type.
Protocols
The following table lists the protocol
parameters that theSunJSSE
provider supports:
Protocol | Enabled by Default for Client | Enabled by Default for Server |
---|---|---|
SSLv3 | No | No |
TLSv1 Footnote 1 | No | No |
TLSv1.1 Footnote 1 | No | No |
TLSv1.2 | Yes | Yes |
TLSv1.3 | Yes | Yes |
SSLv2Hello Footnote 2 | No | Yes |
Footnote 1 -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.
Footnote 2 -The SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols allow you to send SSLv3, TLSv1, TLSv1.1 and TLSv1.2 ClientHellos encapsulated in an SSLv2 format hello by using the SSLv2Hello pseudo-protocol. The following table illustrates which connection combinations are possible when using SSLv2Hellos:
Client | Server | Connection |
---|---|---|
enabled | enabled | Y |
disabled | enabled | Y (most interoperable: SunJSSE default) |
enabled | disabled | N |
disabled | disabled | Y |
Note: The protocols available by default in a JDK release change as new protocols are developed and old protocols are found to be less effective than previously thought. The JDK uses two mechanisms to restrict the availability of these protocols:
- The
jdk.tls.disabledAlgorithms
Security Property: This disables categories of protocols and cipher suites. For example, if this Security Property containsSSLv3
, then the SSLv3 protocol would be disabled. See Disabled and Restricted Cryptographic Algorithms for information about this Security Property. - Moving the protocol to the list of protocols not enabled by default as indicated in the previous table.
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.
- 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 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.
TheSunJCE
Provider
As described briefly in TheSUN Provider, US export regulations at the time restricted the type of cryptographic functionality that could be made available in the JDK. A separate API and reference implementation was developed that allowed applications to encrypt/decrypt data. 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.2.x and 1.3.x. 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:
Engine | Algorithm Names |
---|---|
AlgorithmParameterGenerator | DiffieHellman |
AlgorithmParameters | AESBlowfishDESDESedeDiffieHellmanOAEPPBEPBES2PBEWithHmacSHA1AndAES_128PBEWithHmacSHA224AndAES_128PBEWithHmacSHA256AndAES_128PBEWithHmacSHA384AndAES_128PBEWithHmacSHA512AndAES_128PBEWithHmacSHA1AndAES_256PBEWithHmacSHA224AndAES_256PBEWithHmacSHA256AndAES_256PBEWithHmacSHA384AndAES_256PBEWithHmacSHA512AndAES_256PBEWithMD5AndDESPBEWithMD5AndTripleDESPBEWithSHA1AndDESedePBEWithSHA1AndRC2_40PBEWithSHA1AndRC2_128PBEWithSHA1AndRC4_40PBEWithSHA1AndPC4_128RC2 |
Cipher | See the Cipher table. |
KeyAgreement | DiffieHellman |
KeyFactory | DiffieHellman |
KeyGenerator | AESARCFOURBlowfishDESDESedeHmacMD5HmacSHA1HmacSHA224HmacSHA256HmacSHA384HmacSHA512RC2 |
KeyPairGenerator | DiffieHellman |
KeyStore | JCEKS |
Mac | HmacMD5HmacSHA1HmacSHA224HmacSHA256HmacSHA384HmacSHA512HmacPBESHA1PBEWithHmacSHA1PBEWithHmacSHA224PBEWithHmacSHA256PBEWithHmacSHA384PBEWithHmacSHA512 |
SecretKeyFactory | DESDESedePBEWithMD5AndDESPBEWithMD5AndTripleDESPBEWithSHA1AndDESedePBEWithSHA1AndRC2_40PBEWithSHA1AndRC2_128PBEWithSHA1AndRC4_40PBEWithSHA1AndRC4_128PBKDF2WithHmacSHA1PBKDF2WithHmacSHA224PBKDF2WithHmacSHA256PBKDF2WithHmacSHA384PBKDF2WithHmacSHA512PBEWithHmacSHA1AndAES_128PBEWithHmacSHA224AndAES_128PBEWithHmacSHA256AndAES_128PBEWithHmacSHA384AndAES_128PBEWithHmacSHA512AndAES_128PBEWithHmacSHA1AndAES_256PBEWithHmacSHA224AndAES_256PBEWithHmacSHA256AndAES_256PBEWithHmacSHA384AndAES_256PBEWithHmacSHA512AndAES_256 |
The following table lists cipher algorithms available in the SunJCE
provider.
Algorithm Name | Modes | Paddings |
---|---|---|
AES | ECB, CBC, PCBC, CTR, CTS, CFB, CFB8..CFB128, OFB, OFB8..OFB128 | NoPadding, PKCS5Padding, ISO10126PaddingFootnote 1 |
AES | GCM | NoPadding |
AESWrap | ECB | NoPadding |
ARCFOUR | ECB | NoPadding |
Blowfish, DES, DESede, RC2 | ECB, CBC, PCBC, CTR, CTS, CFB, CFB8..CFB64, OFB, OFB8..OFB64 | NoPadding, PKCS5Padding, ISO10126Padding |
DESedeWrap | CBC | NoPadding |
PBEWithMD5AndDES,PBEWithMD5AndTripleDESFootnote 2,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,OAEPWithMD5AndMGF1Padding,OAEPWithSHA1AndMGF1Padding,OAEPWithSHA-1AndMGF1Padding,OAEPWithSHA-224AndMGF1Padding,OAEPWithSHA-256AndMGF1Padding,OAEPWithSHA-384AndMGF1Padding,OAEPWithSHA-512AndMGF1PaddingOAEPWithSHA-512/224AndMGF1Padding,OAEPWithSHA-512/2256ndMGF1Padding |
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 the last byte, which provides the length of padding, as specified).
Footnote 2PBEWithMD5AndTripleDES 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:
KeyGenerator
Algorithm Name | Default Keysize | Restrictions/Comments |
---|---|---|
AES | 128 | Keysize must be equal to 128, 192, or 256. |
ARCFOUR (RC4) | 128 | Keysize must range between 40 and 1024 (inclusive). |
Blowfish | 128 | Keysize must be a multiple of 8, ranging from 32 to 448 (inclusive). |
DES | 56 | Keysize must be equal to 56. |
DESede (Triple DES) | 168 | Keysize must be equal to 112 or 168.A keysize of 112 will generate a Triple DES key with 2 intermediate keys, and a keysize 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 keysize is 80 or 112 bits respectively. |
HmacMD5 | 512 | No keysize restriction. |
HmacSHA1 | 512 | No keysize restriction. |
HmacSHA224 | 224 | No keysize restriction. |
HmacSHA256 | 256 | No keysize restriction. |
HmacSHA384 | 384 | No keysize restriction. |
HmacSHA512 | 512 | No keysize restriction. |
RC2 | 128 | Keysize 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.
KeyPairGenerator
Algorithm Name | Default Keysize | Restrictions/Comments |
---|---|---|
Diffie-Hellman (DH) | 2048 | Keysize must be a multiple of 64, ranging from 512 to 2048 (inclusive). |
AlgorithmParameterGenerator
Alg. Name | Default Keysize | Restrictions/Comments |
---|---|---|
Diffie-Hellman (DH) | 2048 | Keysize must be a multiple of 64, ranging from 512 to 2048 (inclusive). |
TheSunJGSS
Provider
The following algorithms are available in theSunJGSS
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 theSunSASL
provider:
Engine | Algorithm Names |
---|---|
SaslClient | CRAM-MD5DIGEST-MD5EXTERNALGSSAPINTLMPLAIN |
SaslServer | CRAM-MD5DIGEST-MD5GSSAPINTLM |
TheXMLDSig
Provider
The following algorithms are available in theXMLDSig
provider:
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 |
TheSunPCSC
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. On some operating systems, it may be necessary to enable and configure the PC/SC stack before it is usable. 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
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 to the full filename of an alternate libpcsclite.so
implementation. On Windows platforms, SunPCSC
always calls intowinscard.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 viaTerminalFactory.getDefault()
andTerminalFactory.getInstance("PC/SC")
. If PC/SC is not available or not correctly configured, a getInstance()
call will fail with a NoSuchAlgorithmException
andgetDefault()
will return a JRE built-in implementation that does not support any terminals.
The following algorithms are available in theSunPCSC
provider:
Engine | Algorithm Names |
---|---|
TerminalFactory | PC/SC |
TheSunMSCAPI
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 theSunMSCAPI
provider:
Engine | Algorithm Names |
---|---|
Cipher | RSA RSA/ECB/PKCS1Padding only |
KeyPairGenerator | RSA |
KeyStore | Windows-MYThe keystore type that identifies the native Microsoft Windows MY keystore. It contains the user's personal certificates and associated private keys.Windows-ROOTThe 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-PRNGThe name of the native pseudo-random number generation (PRNG) algorithm. |
Signature | MD5withRSAMD2withRSANONEwithRSARSASSA-PSSSHA1withRSASHA256withRSASHA384withRSASHA512withRSASHA1withECDSASHA224withECDSASHA256withECDSASHA384withECDSASHA512withECDSA |
Keysize Restrictions
The SunMSCAPI
provider uses the following default keysizes (in bits) and enforce the following restrictions:
KeyGenerator
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 (throughSunPKCS11
).
The following algorithms are available in the SunEC
provider:
Engine | Algorithm Name(s) |
---|---|
AlgorithmParameters | EC |
KeyAgreement | ECDHFootnote 1 |
KeyFactory | EC |
KeyPairGenerator | ECFootnote 1 |
Signature | NONEwithECDSAFootnote 1SHA1withECDSAFootnote 1SHA224withECDSAFootnote 1SHA256withECDSAFootnote 1SHA384withECDSAFootnote 1SHA512withECDSAFootnote 1 |
Footnote 1This 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 the previous table won't be available from the SunEC
provider 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, 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 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) or FFDHE (RFC 7919).
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:
KeyPairGenerator
Alg. Name | Default Keysize | Restrictions/Comments |
---|---|---|
EC | 256 | Keysize must range from 112 to 571 (inclusive). |
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 tables below 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. All strings that appear in one row refer to the same curve. For example, the stringssecp256r1
, 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.
Recommended Curves
The following table lists the elliptic curves that are provided by theSunEC
provider and are implemented using modern formulas and techniques. These curves are recommended and should be preferred over the curves listed in the sectionLegacy Curves Retained for Compatibility.
Curve Name | Object Identifier | Additional Names/Aliases |
---|---|---|
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 |
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 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.
Curve Name | Object Identifier | Additional Names/Aliases |
---|---|---|
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 |
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 |
TheOracleUcrypto
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 theOracleUcrypto
provider recognizes.
Note that the OracleUcrypto
provider is included only in Oracle's JDK. It is not part of OpenJDK.
The following algorithms are available in theOracleUcrypto
provider:
Engine | Algorithm Name(s) |
---|---|
Cipher | AESRSAAES/ECB/NoPaddingAES/ECB/PKCS5PaddingAES/CBC/NoPaddingAES/CBC/PKCS5PaddingAES/CTR/NoPaddingAES/GCM/NoPaddingAES/CFB128/NoPaddingAES/CFB128/PKCS5PaddingRSA/ECB/PKCS1PaddingRSA/ECB/NoPadding |
Signature | MD5withRSASHA1withRSASHA256withRSASHA384withRSASHA512withRSA |
MessageDigest | MD5SHASHA-256SHA-384SHA-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
The OracleUcrypto
provider has a configuration file named ucrypto-solaris.cfg
that resides in the$JAVA_HOME/lib/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 ajava.security.KeyStore
that provides access to the macOS Keychain.
The following algorithms are available in the Apple
provider:
Engine | Algorithm Name(s) |
---|---|
KeyStore | KeychainStore |