[Classpathx-crypto] 1 algorithm - many implementations (long)

[Raif S. Naffah]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hello everyone,

in the last few days, and thanks to Dag Arne Osvik contribution and
Casey's work, the prospect of having more than one implementation of the
same Algorithm is now real.

practically speaking, we may have for some algorithms more than one
implementation, each exhibiting different features, and may be in
specific circumstances, better than the other(s).  the problem is then:

1. should we handle this situation? and
2. if yes, how?


except for Mode and Padding, our algorithms can be instantiated with a
public constructor.  this is enough for someone who already _knows_ (a)
how many implementation(s) there are for a given algorithm, and (b) how
they differ from each other (when there's more than one).

but this is not good enough for the majority of users.  they know (or
expected to know) the _environment_ in which the algorithm is supposed
to operate, but not which is the _best_ implementation for that
algorithm in that environment.  it is desirable, if the user can
communicate the description of the operating environment and a set of
preferences, and in return obtain the _right_ implementation for the job.

observation #1: the name of the algorithm alone is not the best way of
selecting one among many implementations of a designated algorithm.

also, in some rare situations -i'll give an example later- a user may
not be interested at all in a specific algorithm but rather in other
criteria that the algorithm's _type_ is capable of providing.  an
example would be to encrypt a username+password for a database user.
the question such user would be asking is: what is the fastest available
implementation of a block cipher that i have which can encrypt 16-byte
at a time, using a 16-byte key?

observation #2: which algorithm to use (the name) may not be the most
important criterion when selecting an implementation.

on the other hand, how can a provider of an algorithm's
implementation(s), know _a priori_ what are the possible user's
preference attributes, so he can accomodate them?  more importatnly, how
can the _seamntics_ of those attributes be interpreted similarly by more
than one provider?

observation #3: there is no universal set of preferences/attributes that
providers can share, or agree to interpret the same way.


now we already have in place a Factory pattern that allows users to
select the algorithm by name; e.g.:

~   gnu.crypto.cipher.CipherFactory.getInstance(foo);

furthermore, we have defined in our API, methods that forces the
implementor to expose some intrinsic attributes of the type of algorithm
being implemented; e.g.:

~   Iterator i = gnu.crypto.cipher.IBlockCipher.blockSizes();
~   Iterator j = gnu.crypto.cipher.IBlockCipher.keySizes();

in addition, at the global level, we have Factory methods to return the
names of all implemented algorithms; e.g.:

~   Iterator i = gnu.crypto.cipher.CipherFactory.getNames();


so what are we missing?

* the name, and some intrinsic attributes related to the type of the
algorithm --and these would change for each type-- are not enough.
intuitively speed should be another factor;  size of the byte-code may
be a factor.  what else?

* the platform is a factor.  java runs everywhere but it does not run
the same way.


hence the questions we should answer (in addition to the initial ones) are:

3. what are the possible criteria a user may specify for selecting an
implementation?

4. can we forsee all possible criteria or should we allow the solution
to cater for criteria that may be added in the future?

5. how are we going to compute/collect/set the values for the selected
criteria in combination with possible environment --i.e. static,
runtime, both?

6. how are we going to let the users tell us what they want? (system
properties, command line options, opaque object in Factory methods)


comments? suggestions?


cheers;
rsn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.1.90 (MingW32)
Comment: Que du magnifique

iD8DBQE9ejkN+e1AKnsTRiERA1Z2AKD+SrjOHTVhdrm7kzhgKu4GX65FNACg/Grj
VGkGYC6LhvMcAll9VWQ/FW0=
=zUh1
-----END PGP SIGNATURE-----