Appendix A: Standard Names

The Java™ 2 SDK Security API requires and uses a set of standard names for algorithms, certificate and keystore types.

In some cases, naming conventions are suggested for forming names that are not explicitly listed to facilitate name consistency across provider implementations. Such suggestions use items in angle brackets (such as <digest> and <encryption>) as placeholders to be replaced by specific message digest, encryption algorithm, and other names.

Note: Algorithm names are not case-sensitive.

This appendix includes corresponding lists of standard names relevant to the various security subareas:

Java Certification Path API Programmer's Guide
JCE Reference Guide
JSSE Reference Guide

For a complete list of standard names, download the jceDocs_samples.zip package in Samples. Extract, locate and run the JCEAlgorithms.java sample.

See Appendix B for algorithm specifications.

Message Digest Algorithms

The algorithm names in this section can be specified when you are generating an instance of MessageDigest.

MD2: The MD2 message digest algorithm as defined in RFC 1319.
MD4: The MD4 message digest algorithm as defined in RFC 1320.
MD5: The MD5 message digest algorithm as defined in RFC 1321.
SHA-1, SHA-224, SHA-256, SHA-384, SHA-512: The Secure Hash Algorithm, as defined in Secure Hash Standard, NIST FIPS 180-2.

Key and Parameter Algorithms

The algorithm names in this section can be specified when you are generating an instance of KeyPairGenerator, KeyFactory, AlgorithmParameterGenerator, and AlgorithmParameters.

DSA: The Digital Signature Algorithm as defined in FIPS 186-2.
EC: The Elliptic Curve Algorithm.
RSA: The RSA encryption algorithm as defined in PKCS #1.

Digital Signature Algorithms

The algorithm names in this section can be specified when generating an instance of Signature.

MD2withRSA: The MD2 with RSA Encryption signature algorithm that uses the MD2 digest algorithm and RSA to create and verify RSA digital signatures as defined in PKCS #1.
MD5withRSA: The MD5 with RSA Encryption signature algorithm that uses the MD5 digest algorithm and RSA to create and verify RSA digital signatures as defined in PKCS #1.
SHA1withDSA: The DSA with SHA-1 signature algorithm that uses the SHA-1 digest algorithm and DSA to create and verify DSA digital signatures as defined in FIPS 186-2.
SHA1withRSA: The signature algorithm with SHA-1 and the RSA encryption algorithm as defined in the OSI Interoperability Workshop, using the padding conventions described in PKCS #1.
<digest>with<encryption>: Use this to form a name for a signature algorithm with a particular message digest (such as MD2 or MD5) and algorithm (such as RSA or DSA), just as was done for the explicitly defined standard names in this section (MD2withRSA, and so on). For the new signature schemes defined in PKCS #1 v2.0, for which the <digest>with<encryption> form is insufficient, <digest>with<encryption>and<mgf> can be used to form a name. Here, <mgf> should be replaced by a mask generation function such as MGF1. Example: MD5withRSAandMGF1.
RSAPSS: RSA-PSS is a signature scheme that is based on the RSA cryptography system and is described in version 2.1 of PKCS #1. Like other digital signature schemes, the following processing steps take place during signing:
- The signature scheme hashes the message to be signed by using a hash function.
- The resulting hash is transformed into an encoded message.
- A signature primitive is applied to the encoded message by using the private key to produce the signature.
Unlike other digital signature schemes, the transform operation uses padding that is much more random. During the signature verification process, the following processing steps take place:
- The scheme hashes the message to be signed by using the same hash function that was used to sign the message.
- A verification primitive is then applied to the signature by using the public key of the key pair to recover the message.
- The scheme verifies that the encoded message is a valid transformation of the hash value.

Random Number Generation (RNG) Algorithms

The algorithm names in this section can be specified when generating an instance of SecureRandom.

IBMSecureRandom: The name of the random number generation algorithm supplied by the IBMJCE provider. This implementation uses an MD5 message digest and computes the hash over a true-random seed value.
SHA1PRNG: The name of the pseudo-random number generation (PRNG) algorithm supplied by the IBMJCE provider. This implementation uses a SHA-1 message digest and computes the hash over a true-random seed value. The implementation supports a customizable source for seed data. By default, an attempt is made to use the entropy gathering device specified by the securerandom.source security property in the java.security file. The entropy gathering device can also be specified with the system property java.security.egd. Specifying this system property overrides the securerandom.source security property. On Windows systems, specifying a URL of file:/dev/random or file:/dev/urandom for the seed source enables the native Microsoft CryptoAPI seeding mechanism. If an exception occurs while accessing the specified seed source, a traditional system or thread activity algorithm is used.
HASHDRBG: This algorithm implements the HASH_DRBG algorithm found in NIST SP 800-90. This implementation uses a SHA-256 message digest. If no seed is provided, one is obtained from SHA1PRNG.
SHA256DRBG: This algorithm implements the HASH_DRBG algorithm found in NIST SP 800-90. This implementation uses a SHA-256 message digest. If no seed is provided, one is obtained from SHA1PRNG.
SHA512DRBG: This algorithm implements the HASH_DRBG algorithm found in NIST SP 800-90. This implementation uses a SHA-512 message digest. If no seed is provided, one is obtained from SHA1PRNG.
NativePRNG: Available on operating systems like AIX® and Linux®. Method nextBytes() uses /dev/urandom. Method generateSeed() uses the entropy gathering device specified by the securerandom.source security property in the java.security file. The entropy gathering device can also be specified with the system property java.security.egd. Specifying this system property overrides the securerandom.source security property. If an exception occurs while accessing the specified seed source, a default value of /dev/random is used. If neither the specified seed source or /dev/random are available, the implementation is disabled.
NativePRNGBlocking: Available on operating systems like AIX and Linux. Methods nextBytes() and generateSeed() both use /dev/random.
NativePRNGNonBlocking: Available on operating systems like AIX and Linux. Methods nextBytes() and generateSeed() both use /dev/urandom.

Certificate Types

The types in this section can be specified when you are generating an instance of CertificateFactory.

X.509: The certificate type defined in X.509.

Keystore Types

The types in this section can be specified when you are generating an instance of KeyStore.

DKS: Domain keystore type
JCEKS: The proprietary keystore type supplied by the IBMJCE provider. For more information, see JCE Keystore.
JKS: The name of the keystore implementation supplied by the IBMJCE provider.
PKCS12: The transfer syntax for personal identity information as defined in PKCS #12. Implementation supplied by the IBMJCE provider.

Service Attributes

A cryptographic service is always associated with a particular algorithm or type. For example, a digital signature service is always associated with a particular algorithm (such as DSA), and a CertificateFactory service is always associated with a particular certificate type (such as X.509).

The attributes in this section are for cryptographic services. The service attributes can be used as filters for selecting providers.

The attribute name and value are not case sensitive.

KeySize: The maximum key size that the provider supports for the cryptographic service.
ImplementedIn: Whether the implementation for the cryptographic service is done by software or hardware. The value of this attribute is software or hardware.