Home Page Javascript Download Core Servlets & Java Server Java Cryptography Java in 60 Min A Day Javascript Tutorial About Us Contact Us
Site Search
Free Javascript Lessons
Newest Java Articles
Checkbox Changer
Check Entry
Check All
Block Key Press
Basic Validation
Auto Email Link
JavaScript Forms: Agree Before Entry
Auto Tab
JavaScript Calendars: Time Entered - Day Highlighted
JavaScript Calendars: Days Left
Related SE Keywords
Java virtual machine
Java Applet
Javascript Lesson
Javascript Tutorial
Java Programming
Java Games
Java Xml
Java String
Cryptography Extensions
Free Web Master Tools
JavascriptDownload.net > Free Javascript Lessons > Java Cryptography Extensions > Chapter 1 / 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 infor­mation, 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) {






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:


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.
















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]);



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)





} 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


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


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


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


   1.7 Working with Jurisdiction Policy Files        27


SHAlwithRSA as implemented in class


SHAlwithRSA is also aliased to the name SHA-1/RSA/PKCS#1

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:

Signature signature = Signature.getlnstance("MD4withRSA");

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 regis­tered 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:

Signature signature = Signature.getlnstance("MD4withRSA");

Signature signature = Signature.getlnstance("MD4/RSA/PKCS#1");

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 imple­ment 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.


1.7 Working with Jurisdiction Policy Files

Most of us write applications that are run internally throughout the corporate environment. However, some of us find ourselves in the unique position of writing applications that are

going to be exported. Unfortunately developers are not immune from the political lines drawn on a map, and, as a result, some care must be taken to ensure laws are not broken if the software is going to be exported. This section is aimed squarely at those developing commercial software applications that are going to be exported. Ironically, the problem may not necessarily reside with the exporting country but rather the importing country.

By default, the JDK 1.4 jurisdiction policy files support what is known as "strong but limited" cryptography. An "unlimited strength" policy file is available for download from http://java.sun.com for those living in eligible countries. The JCE will enforce this policy file, limiting things like the maximum key size that a cipher can use when encrypting. There isn't much value in reprinting the process one goes through to deliver an "exempt" application. For more information, grab a copy of the JCE documentation [5] and review "How to Make Applications 'Exempt' from Cryptographic Restrictions" and the sections that follow it.

Add Comment
homepage   |  about us  |  contact us
Powered By teknonova.com Sunucu Kiralama