9 - Code Example: Obtaining a List of Installed Algorithms

1.6.5 Code Example: Obtaining a List of Installed Algorithms

Perhaps one of the most common questions fielded from new JCE developers is how to determine what algorithms are installed, or more specifically, what are the formal names of the installed algorithms. There are two different techniques for obtaining this information, and both key off of the formal engine name, for example, Signature or Message Digest or Cipher. The first technique is via the Security class. It declares an elementary java.util.Set getAlgorithms(String engineName) method. Iterate over the set and you see the proper names for each algorithm registered with the engine.

Example 1.4 Sample Code Location: com.mkp.jce.chapl .SimpleEngineListing

//Dynamically register our Cryptix provider

//without requiring java.security modification

//Place the provider in the fifth position

//Provider prov = new cryptix.jce.provider.CryptixCryptoO;

//Security.insertProviderAt(prov, 5);

Set set = Security.getAlgorithms(args[0]); Iterator iter = set.iterator();

while (iter.hasNextO) {

System.out.println(iter.next().toStringO);

}

This small code sample produces algorithm names that can be effectively used in an opaque provider strategy. Nothing about the provider that implements the algorithm is revealed—the algorithm essentially remains a black box.

This code sample also demonstrates the use of the Security class to dynamically register new JCE providers. Running the code with the dynamic registration commented out should reveal a small list similar to this for the Signature engine:

MD2WITHRSA SHA1WITHRSA SHA1WITHDSA MD5WITHRSA

Now, if we uncomment the two lines of code that dynamically register the Cryptix provider, we should see a much larger list of algorithms that the Signature engine supports.

MD2WITHRSA

RIPEMD128WITHRSA

SHA/DSA

SHA-384/RSA/PKCS#l

SHA1WITHRSA

SHA1WITHDSA

RSASSA-PSS/SHA-1

RSASSA-PSS/SHA-512

RSASSA-PSS/SHA-384

RSASSA-PSS/SHA-256

RIPEMD160WTTHRSA

SHA-256/RSA/PKCS#l

MD5WITHRSA

SHA-512/RSA/PKCS#1

RAWDSA MD4WITHRSA

The other technique for locating the nomenclature of the installed algorithms is via the Provider class. Let's see an example of this approach:

Example 1.5 Sample Code Location: com.mkp.jce.chapl.CompleteEngineListing

try {

//Dynamically register our Cryptix provider

//without requiring java.security modification

//Place the provider in the first position

Provider prov = new cryptix.jce.provider.CryptixCrypto();

Security.insertProviderAt(prov, 1);

Provider provider = Security.getProvider(args[0]);

System.out.println(provider.getNameO + "-" + args[l] + "engine :\n");

Enginelterator iter = new Enginelterator(provider, args[l]);

while(iter.hasNext())

{

Map.Entry entry = (Map.Entry) iter.nextO;

if( liter. isAliasO)

{

_description =

entry.getKeyO .toStringO . substring(l +

args[l] .lengthO) + " as implemented in class " +

entry.getValueO .toStringO;

} else {

_description =

entry.getValueO .toStringO + " is also aliased as" + entry.getKeyO .toStringO. substring(

Enginelterator.ALGORITHM_ALIAS.lengthO + args[l] .lengthO + 1);

}

//Add our description to our sorted list _sortedListing.add(_description);

}

Iterator printlter = _sortedListing.iterator();

while (printlter. hasNext 0)

{

System.out.println(printlter.next().toStringO)I

}

} catch (ArraylndexOutOfBoundsException aioobe) {

System.err.println("Usage: java EngineListing providerName engineType"); System.err.println("Engine names are case-sensitive");

}

This example uses a utility class I threw together called Enginelterator. It essentially is a class that implements the java.util.Iterator interface, and provides some logic for skipping over the extraneous entries from engines we aren't interested in viewing. This isn't a book on the Java Collections, so we'll treat the Enginelterator as a black box utility class. Running this code for the CryptixCrypto provider, Signature engine reveals the following output:

CryptixCrypto formally supports the following implementations for the Signature engine :

MD2withRSA as implemented in class cryptix.jce.provider.rsa.RSASignature_PKCSl_MD2

MD2withRSA is also

aliased to the name MD2/RSA/PKCS#1 MD4withRSA as implemented in class

cryptix.j ce.provider,rsa.RSASignature_PKCSl_MD4 MD4withRSA is also aliased to the name MD4/RSA/PKCS#1 MD5withRSA as implemented in class

cryptix.jce.provider.rsa.RSASignature_PKCSl_MD5 MD5withRSA is also aliased to the name MD5/RSA/PKCS#1 RIPEMD128withRSA as implemented in class cryptix.jce.provider.rsa.RSASignature_PKCSl_RIPEMD128 RIPEMD128withRSA is also aliased to the name RIPEMD-128/RSA/PKCS#1 RIPEMD160withRSA as implemented in class

cryptix.jce.provider.rsa.RSASignature_PKCSl_RIPEMD160 RIPEMD160withRSA is also aliased to the name RIPEMD-160/RSA/PKCS#1 RSASSA-PSS/SHA-1 as implemented in class

cryptix.jce.provider.rsa.RSASignature_PSS_SHAl RSASSA-PSS/SHA-256 as implemented in class cryptix.jce.provider.rsa.RSASignature_PSS_SHA2 5 6 RSASSA-PSS/SHA-384 as implemented in class cryptix.jce.provider.rsa.RSASignature_PSS_SHA384 RSASSA-PSS/SHA-512 as implemented in class cryptix.jce.provider.rsa.RSASignature_PSS_SHA512

RawDSA as implemented in class cryptix,jce.provider.dsa.RawDSASignature

SHA-256/RSA/PKCS#l as implemented in class

cryptix.jce.provider.rsa.RSASignature_PKCSl_SHA256

SHA-384/RSA/PKCS#l as implemented in class

cryptix.jce.provider.rsa.RSASignature_PKCSl_SHA384

SHA-512/RSA/PKCS#1 as implemented in class

cryptix.jce.provider.rsa.RSASignature_PKCSl_SHA512

SHA/DSA as implemented in class cryptix.jce.provider.dsa.DSASignature

The generated output provides further insight into how the JCE architecture supports many common names for a single algorithm. All of the Alg.Alias entries we saw when we ran the DisorganizedListing for the SUN provider should now make sense after seeing this example. Take a look at the MD4withRSA signature. Let's look at what happens when this one line of code is invoked:

When the Signature engine's factory method receives a request to provide a class that implements the MD4withRSA algorithm, it searches through the provider's in their registered prioritized sequence. When it finds a provider that offers a solution to this request, the engine grabs the fully qualified class name (it is implemented in a concrete class cryptix.jce.provider.rsa.RSASignature_PKCSl_MD4) and issues a Class.forNameO to load the implementing class. Contractually via the SPI, this class extends the Signature class, and after an instance of it is created, it is returned (cast to its ancestor, the Signature class) from the call. What our listing demonstrates is that the following two lines of code accomplish the same thing, instantiating an identical class:

As we can see, the architecture is extremely robust, allowing each algorithm to expose itself under any number of different names. However, this "feature" is really a double-edged sword. The JCA fails to define a formal algorithm namespace. The implication of this missing namespace is best conveyed through an example. Imagine two third party providers A and B are installed in that order. Provider A may implement an algorithm for use in the MessageDigest engine with a name of "MD-5" while provider B may implement an identical algorithm, but name it "MD5" instead. The algorithm names are strings arbitrarily chosen by the provider! If a developer requests an "MD5" algorithm from the engine, provider A won't be considered because it doesn't implement an "MD5" algorithm. As a result, it puts an undue burden on both providers and developers. Providers are forced to alias out each of their implementations with many common names to ensure they get adequate consideration during an algorithm search, and developers struggle with an ever-growing combination of arbitrary names from providers.