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 / 8 - Code Example: Listing a Provider's Supported Algorithms

1.6.4  Code Example: Listing a Provider's Supported Algorithms

The Provider class defines an un-modifiable view into the engine algorithms that the provider supports, as depicted in Figure 1.2. This is inline with the notion that the Provider class is strictly about metadata, and supports our statement that developers will rarely directly interact with one of the Provider subclasses. We've already described the search preference for providers that is used when an engine's getlnstanceO factory method is invoked. As the factory method iterates over the providers in their preferred search sequence, each Provider implementation is queried to determine if it has implemented the requested algorithm.

Conceptually, the lookup is very simple. The Provider class declares an entrySetO method that returns a java. util. Set of Map. Entry objects. Each Map. Entry object contains a name-value pair that represents either a concrete implementation or an aliased name that points to a concrete implementation. For example, let's say that we invoked the following Signature engine factory method:

Signature mySignature = Signature.getInstance("SHAlwithDSA");

The argument indicates that we are requesting a SHA-1 with DSA signature algorithm. We also are using an opaque algorithm strategy, so each provider will be searched in the order defined by the java.security file—taking into consideration any dynamically registered providers and their requested priority. Using the same java. security file doc­umented earlier in this chapter (and assuming no dynamically registered providers exist), we see that the SUN provider is first in our list. Let's see what algorithms this provider supports.

Example 1.3 Sample Code Location: com.mkp.jce.chapl .DisorganizedListing

try {

//Lookup the named provider using its formal name Provider provider = Security.getProvider(args[0]);

 

System.out.print(provider.getName());

System.out.printlnC formally supports the following algorithms:");

 

//Step over the list of supported algorithms Iterator iter = provider.entrySet().iteratorQ; while(iter.hasNext()) {

Map.Entry entry = (Map.Entry) iter.next(); System.out,println("\t" +

entry. getKeyO + " = " + entry. getValueO);

}

} catch (NullPointerException nspe) {

//NPE means Provider wasn't found 1

System.err.println("The provider you requested is not installed in the

JRE");

} catch (ArraylndexOutOfBoundsException aioobe) {

System.err.println("Usage: java ProviderDetail providerName");

}

 

Running this code example produces the following abbreviated output. Notice in particular the three bold lines that relate to our SHA-1 with DSA request:

wiseman in ~/src/jce (ll)--> java com.mkp.jce.chapl.DisorganizedListing SUN

 

Alg.Alias.KeyFactory.1.2.840.10040.4.1 = DSA

Alg.Alias.Signature.1.2.840.10040.4.3 = SHAlwithDSA Alg.Alias.KeyPairGenerator.OID.1.2.840.10040.4.1 = DSA CertStore.LDAP LDAPSchema = RFC2587 Signature.SHAlwithDSA KeySize = 1024 Signature.SHAlwithDSA Implementedln = Software

CertPathValidator.PKIX ValidationAlgorithm = draft-ietf-pkix-new-partl-08.txt

CertPathBuilder.PKIX = sun.security.provider.certpath.SunCertPathBuilder Alg.Alias.KeyFactory.1.3.14.3.2.12 = DSA

CertStore.LDAP = sun.security.provider.certpath.LDAPCertStore AlgorithmParameterGenerator.DSA =

sun.security.provider.DSAParameterGenerator Alg.Alias.KeyPairGenerator.1.3.14.3.2.12 = DSA Alg.Alias.Signature.SHA/DSA = SHAlwithDSA Alg.Alias.Signature.1.3.14.3.2.13 = SHAlwithDSA SecureRandom.SHAlPRNG = sun.security.provider.SecureRandom Alg.Alias.Signature.DSS = SHAlwithDSA CertStore.Collection =

sun.security.provider.certpath.CollectionCertStore KeyFactory.DSA Implementedln = Software KeyStore.JKS Implementedln = Software Signature.SHAlwithDSA = sun.security.provider.DSA MessageDigest.SHA Implementedln = Software

Based on this information, the factory method of the Signature engine is able to effectively determine the following four items from the SUN provider:

1.  The SUN provider offers an implementation of the SHAlwithDSA algorithm

2.  The actual class that implements the algorithm can be found in sun.security. provider.DSA. This can be verified through a javap command on the command line which shows that the class extends the java.security.Signature class

3.   The implementation in question is software (as opposed to hardware) based; for example, some type of cryptographic device attached to a serial or USB port)

4.   The implementation uses a key that is 1024 bits in size.

Also of interest in this file is the use of a string naming convention that allows quick lookups without iterating over every key. With the exception of the Alg.Alias prefix (which is a special case for aliasing algorithms that go by many different names), the prefix prior to the first '.' in the key name equates to the type of engine, and the suf­fix after the first'.' in the key name corresponds with the proper algorithm name. Using this notation, the Signature factory method—as well as any engine's factory method— can quickly and effectively determine if a provider implements the requested algorithm. Using the read-only metadata stored in the Set, the factory method simply looks for the pattern "<EngineType>.<AlgorithmName>" and if found, the algorithm is supported and the value of that key is the name of the concrete class that implements the algorithm. The factory then creates an instance of the class (usually through a Class.forNameQ lookup-instantiation design) and returns it, which the JVM will automatically cast to the appro­priate engine type. If we wanted to determine if a provider supported an MD5 message digest, the Message Digest engine's factory method simply looks up each provider (if not explicitly named) and attempts to locate a key named MessageDigest .MD5 in the metadata.

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