# Getting classes from providers

Steve Burnett (burnettS@RSA.COM)
Fri, 9 May 1997 14:03:38 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: GBLOT@aol.com: "Error?Bug?Error?Bug? on java?"
- Previous message: Tim Wolters: "SecureRandom"

    Message-Id: <c=US%a=_%p=RSA_Data_Securit%l=LOBESTER-970509210338Z-4608@LOBESTER.rsa.com>

    From: Steve Burnett <burnettS@RSA.COM>

    To: "'JavaSoft crypto questions'" <java-security@web2.javasoft.com>

    Subject: Getting classes from providers

    Date: Fri, 9 May 1997 14:03:38 -0700

When an application calls the JCE Cipher.getInstance (String
algorithm) routine, eventually Security.getImpl --by calling
getEngineClassName-- will ask the provider to return the name of the
class associated with that String algorithm. getImpl then will use the
Class class to create a newInstance of that class.

How about this? getImpl does not ask for a class name associated with
the Sting algorithm, but rather the String type. The String type is
"Cipher" or "Signature".

Now, the provider returns its implementation of Cipher, maybe we at
RSADSI for example would call it JA_Cipher, which is subclassed off of
the JCE Cipher.

Then Cipher.getInstance would instantiate that class and pass the
String algorithm to this new object.

It looks like this

Application developer calls Cipher.getInstance ("RC2-80/CBC/PKCS#5")
Cipher.getInstance calls Security.getImpl ("Cipher")
Securitly.getImpl calls getEngineClassName (type) remember, type
is "Cipher"
the engine has returned the class name of its Cipher class
(say JA_Cipher).
getImpl returns this name to the caller
Cipher.getInstance, through the Class class can get a newInstance of
JA_Cipher.
Cipher.getInstance calls this object's (the instantiation of
JA_Cipher)
setAlgorithm (algorithm). Remember, algorithm = "RC2-80/CBC/PKCS#5".

This requires every provider to supply a Cipher or Signature or
MessageDigest and so on class (if they support an algorithm of that
type) and their class must contain a setAlgorithm method.

As a provider, rather than supply a separate class for each possible
String algorithm we can handle, we can provide one class that will
contain a method to parse that String. If parameters are part of the
string, we would have to either limit our customers to a few "popular"
parameters or write many, many classes. Even taking away parameters, the
possible algorithm/feedback/padding combinations can still be very large
and unwieldy. It is simply a bit inefficient.

- Next message: GBLOT@aol.com: "Error?Bug?Error?Bug? on java?"
- Previous message: Tim Wolters: "SecureRandom"