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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
