# Comment on the provider architecture of java.security.Security

Vishal Goenka (vgoenka@novell.com)
Mon, 06 Jul 1998 03:38:33 -0600

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Vishal Goenka: "Comment on the provider architecture of java.security.Security"
- Previous message: Oukhellou: "error of security?"

    Message-Id: <s5a046d0.038@novell.com>

    Date: Mon, 06 Jul 1998 03:38:33 -0600

    From: "Vishal Goenka" <vgoenka@novell.com>

    To: java-security@java.sun.COM

    Subject: Comment on the provider architecture of java.security.Security

This comment addresses a specific feature of java.security.Security class =
(henceforth called Security), relating to the way the provider's implementa=
tion classes are instantiated.

The static getInstance() method of each of the crypto engines (MessageDiges=
t, Signature ...) invoke the Security.getImpl() method, which searches the =
appropriate provider (as specified, or others if not) for a String =
property containing the name of the provider's actual impementation class =
implementing the required algorithm. The provider class is instantiated =
using the default constructor (using class.forName(name).newInstance()). =
This framework is fine for most providers.

There is one instance however, where this doesn't seem quite neat. Assume =
that one needs to write a security provider in Java that exposes the =
crypto algorithms already implemented in C (via JNI). Java purists may =
outrightly reject that option, but notwithstanding them, lets continue. To =
be more specific, lets assume that one needs to expose the various message =
digest algorithms available in the C implementation (MD2, MD4, MD5, SHA1) =
using the JCA classes. The current framework would require writing 4 =
provider classes, one for each of the above message digest algorithms. =
This would be fine if the actual bodies (the mathematical operations) were =
coded in Java. However, if the actual bodies reside in a C implementation, =
all the 4 required classes would be dummy wrappers, which would invoke =
their C counterpart, with a different algorithm parameter. (As done in the =
Bsafe toolkit). It would be simpler for the provider to use a single =
implementation class for MessageDigest instead, which could be initialized =
with the appropriate algorithm during instantiation, (one of the above 4 =
in this case), since all other operations are identical for each algorithm.=
=20

For operations like Cipher, where the number of algorithms available could =
be too many. it would be a much greater pain to provide a specific =
implementation class for each algorithm available in the C implementation. =
It also doesn't scale well, in the sense that for each new algorithm added =
to the C implementation an equivalent wrapper needs to be added to the =
java set of classes.=20

I would like to suggest a simple addition to the semantics of Provider =
class, and a modification in the Security code to address the above =
inconvenience. The implementation strategy could be modified though, so =
long as the essence of functionality is provided.

The basic idea is to allow the crypto provider's "Provider" (subclass of =
java.security.Provider) return an instantiated engine object rather than =
restrict it to return the name of the class implementing the engine =
(String). The crypto Provider could for instance instantiate the appropriat=
e engine using the appropriate constructor, thereby initializing the same =
engine with the required algorithm. The crypto Provider may invoke =
implementation specific calls to query the underlying C implementation =
(via JNI) for the required algorithm. If the underlying implementation =
supported the required algorithm, (say SHA1), the provider's message =
digest class (say) MyMessageDigest could be instantiated using a constructo=
r which accepted algorithm specific details (in this case, SHA1). This =
would provide transparent addition of more algorithms in the C implementati=
on, without modifying the java code base.

One way (not the only one) to accomodate the above requirement is to =
provide a method=20
public abstract Object getImpl(String algorithm, String engineType)=20
{
return null;
}

in the java.security.Provider, which would return the appropriately =
instantiated (and initialized) implementation class for the required =
algorithm, or null by default. (Subclasses need to override to provide =
meaningfull functionality)
The Security class code would first invoke the provider's getImpl() method =
allowing the provider to do a provider-specific instantiation of the =
implementation class. If this returns null, the getProperty method can be =
invoked, as done currently.

I would be glad to discuss this even further, if I haven't been too clear =
above.=20

Best regards,
Vishal

- Next message: Vishal Goenka: "Comment on the provider architecture of java.security.Security"
- Previous message: Oukhellou: "error of security?"