[GNU Crypto] JCE Adapters

[Raif S. Naffah]

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

hello there,

with Casey's latest checkins, GNU Crypto _is_ a JCE/JCA Provider 
implementation, for _all_ provided algorithms of the type supported by 
the JCE/JCA framework, as well as being usable as a self-sufficient 
cryptographic library without any additional overhead.

not being constrained by the JCE/JCA framework, the library explores new 
ideas in implementing complex cryptographic algorithms such as the UST, 
and exposing re-usable methods in some algorithms that are used in 
others (e.g. SHA-160 and DSS keypair generation).

furthermore, the GNU Crypto library aims at maximising the performance 
of the implemented algorithms for GCJ-built shared reloadable (.so)
native libraries.


neither GNU Classpath, nor GNU Classpath Extensions, offer a JCE/JCA 
implementation of that framework, but open source implementations, with 
compatible licensing terms to those adopted for both above mentioned 
projects, as well as to ours, exist.  it is felt at this stage that any 
of those existing JCE/JCA framework implementations could/should be 
used.  in addition, whatever will be the adopted as the GNU JCE/JCA 
framework implementation, GNU Crypto should be 100% compatible with it.

this situation should now be reflected in our build process.  the 
following is a list of the requirements:

1. the GNU Crypto binaries should be divided into two: gnu-crypto.jar 
and gnu-crypto-jce.jar.  the latter containing the JCE Adapters to 
allow the former to be installed/used as a JCE Provider.

2. decide whether the same should be done for the current 
gnu-crypto-test.jar.

3. allow configuration of a JCE/JCA framework implementation to be used 
while developing and testing the library.  ultimately, these 
implementations should contain (a) the GNU adopted implementation, (b) 
the bouncycastle implementation and (c) the cryptix implementation.  
something similar to what we currently do with JUnit (ant build) may be 
needed with some distributions to separate the framework from the 
publisher's own provider implementation, if both are bundled in the 
same jar/zip file.  furthermore, this step may be complicated by some 
publishers having different distributions based on the target JDK.

4. offering fast algorithms for both GCJ-built shared reloadable native 
libraries and pure java jars, for some algorithms, requires different 
sources; e.g. Serpent and SerpentBitSlice.


comments are welcome + cheers;
rsn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE91Y8S+e1AKnsTRiERAxbSAKCksxL+ENlTp3XJ1IX4Of//ZZgYjQCeM25z
ouDheo2A0Jw0UGGvST5NASA=
=AWlN
-----END PGP SIGNATURE-----