Name: rmT116609 Date: 10/13/2003


A DESCRIPTION OF THE REQUEST :
There is no way given the current JCA specification to pass algorithm specific parameters to a MessageDigestSpi implementation.

JUSTIFICATION :
This precludes the ability to supply single class implementations for digest functions with multiple parameters or parameters with a wide range of variants or rounds. SNEFRU, HAVAL, TIGER, and a number of other MessageDigests cannot be effectively implemented in the current API (without only supplying an implementation for the default configuration.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
There are two ways this can be accomplished:

The simplest way would be to add a concrete method to the MessageDigestSpi abstract base class such as:

public void engineParameters(String name) {} with an empty implementation

and then to allow the default Provider interface to find:

MessageDigest.HAVAL

when you invoke

MessageDigest.getInstance("HAVAL(20,5)"); // aka OpenPGP.Digest.7

first trying to find a Digest fully qualified as 'MessageDigest.HAVAL(20,5)' and then after stripping out ()'s for 'MessageDigest.HAVAL', creating the object, and finally invoking engineParameters on the result with the fully qualified name.

This would result in behavior compatible with the namings defined by:
http://www.users.zetnet.co.uk/hopwood/crypto/scan/intro.html

Alternatively the extra parameters or name could be passed to an alternate constructor, although this alternative might cause conflicts with existing end-user hacks to try to obtain a crippled version of this functionality.

There is already a precedent for mangling text in the Security interface before passing it to the Provider in the JCE, which searches for variants of Algorithm/Mode/Padding, Algorithm/Mode, Algorithm//Padding, etc..

Another answer would be to allow a subclass of java.security.spec.AlgorithmParameterSpec to be passed to a new method on MessageDigest and passsed along to a new concrete but overridable method on the MessageDigestSpi, however, this would make parameterized algorithms more difficult to use.
ACTUAL -
Attempts to find an MessageDigest implementation look for the exact name entered into the getInstance call. It is not possible to simply (even if inefficiently) an implementation for every number of rounds and keysize variants, because it is not possible to catch the algorithm name invoked in the MessageDigestSpi implementation (the information is discarded along the way), without subclassing your MessageDigestSpi for every possible parameter combination, which is impossible for open sets.



---------- BEGIN SOURCE ----------
MessageDigest md = MessageDigest.getInstance("HAVAL(5,20)","KmettCP");
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Counterintuitively implement MessageDigest algorithms as javax.crypto.MacSpi implementations.

However MessageDigests and MACs serve different roles. This also does not allow plug-in usage along-side other MessageDigest code.
(Incident Review ID: 201361)
======================================================================