GNU Classpath, gcj and Crypto update

[Mark Wielaard]

Hi all,

Here is a small update on the progress of the security and crypto
classes.

After discussing this a little bit off list with the GNU Crypto,
Classpath and libgcj maintainers we decided to work towards the
following situation:

- GNU Classpath provides a java.security framework and the basic
algorithms needed to implement the core libraries (only MD5/SHA Message
Digests, DSA KeyPairGenerator, SHAwithDSA Signature and a basic
SecureRandom and KeyStore implementation). Everything that is not needed
to implement the core libraries would be pushed into GNU Crypto.

- The GNU Crypto package comes with crypto algorithms and a JCA/JCE
wrapper/provider (build produces gnu-crypto.jar and lib-gnu-crypto.so).
(See http://www.gnu.org/software/gnu-crypto/#status for the supported
algorithms.)

- The JCE framework (javax.crypto package) from BouncyCastle is imported
into the GNU Crypto tree. And developers get a choice (configure option)
to build/install the javax-crypto jar and shared library
(lib-javax-crypto.so) if they want.

- If all the above is installed correctly then a developer only has to
add the GNU Crypto JCE wrapper gnu.crypto.jce.GnuCrypto provider to the
security properties file to automatically use all the new algorithms.

- GNU Classpath and libgcj explicitly point people to GNU Crypto for
full security algorithm support. GNU Crypto comes with implementations
of some of the algorithms that are optimized for gcj ahead of time
compilation. See the following for a speed hit parade:
http://mail.gnu.org/pipermail/gnu-crypto-discuss/2002-December/000057.html

The main reason for this setup is that it is best if GNU Crypto comes in
a way that makes it buildable/workable out of the box with any
Classpath/gcj based system. And that it keeps all crypto stuff in one
place so that only the GNU Crypto developers have to worry about US
export stuff.

We hope that this setup will be completed when gcj 3.3 is released. Most
of the necessary work and bug fixing has already been done in the last
couple of weeks/months. The GNU Crypto non-JCE stuff can already be used
with gcj 3.1/3.2 but some bugs (fixed in 3.3) prevent it from being
compiled at -O2 which makes it a lot slower then necessary.

This is what needs to be done:

- There seems to be a bug in java.math.BigInteger.euclidInv which throws
AlgorithmException("not invertable"). Casey Marshall tracked this issue
down and posted about it on the GNU Classpath mailing list, but it seems
to have not shown up in the archives yet.

- java.security startup refs "GNU libgcj.security"
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&database=gcc&pr=7416
Tom Tromey had a suggestion for a bug fix.

- Finalise the GNU Crypto regression tests. Raif Naffah already did most
of the work for this.

- Import the javax.crypto classes into GNU Crypto source/javax
hierarchy. Casey Marshall already has this working outside the GNU
Crypto source tree <http://metastatic.org/src/jce-1.16.tar.gz>.

- We are looking for someone to work on a KeyStore implementation. Joerg
Brunsmann suggested to support PKCS12 as standard format and maybe add
read support for the proprietary JKS format (if we can find specs or
reverse engineer it).

Cheers,

Mark