Sun Jul 16 16:24:21 EST 2000
This JCE derived from the ABA JCE v1.1. It differs from it in terms of a number of enhancements and some repackaging. For the official ABA JCE see www.esec.net.au (formerly www.aba.net.au).
Details of the changes can be found in the relevant source files, however, in short this JCE differs from the conventional ABA one in the following respects:
A lot of the above changes were made possible by patches submitted on the ABA jce mailing list (see below for subscription details). The current contributors list:
If you find any problems with this particular release please send mail to jce-feedback@wumpus.com.au, anything we have changed is not ABA's fault! We live a bit closer to the edge.
For general discussion about this release we encourage you to subscribe to list-jce-subscribe@aba.net.au. This is the standard ABA list but in terms of how this style of JCE works the information you will find there will prove to be useful.
Except where otherwise stated, this package is covered by the ABA Public Licence. Please ensure you review this licence before making use of this package.
The ABA JCE is a clean room implementation of the Java Cryptography Extension (JCE) 1.2 API as defined by Sun MicrosystemsTM, plus a provider of underlying crypto algorithms. This package does not include any native code.
To make use of this package simply include jce.zip in your class path. If you want to run the tests you also need to include test.zip. If you have any questions as to how to do this the supporting documentation for your Java runtime should explain how to do this.
The following is a summary of the pertinent notes (plus the extra algorithms) in the original ABA distribution (if you want to read the originals look here).
The JDK 1.2 version supports:
Currently both the au.net.aba.crypto.provider.DESKey and au.net.aba.crypto.provider.RC4Key Key classes implement the Externalizable interface. Strictly speaking this is undesirable since it makes these objects mutable (ie a given instance may be altered within the runtime). If there is no requirement to support serialisation of keys to and from 1.0, it is recommended to remove the Externalizable interface support from the Key classes that currently implement it.
Sun, Java, Java Developer Connection are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Other trademarks mentioned are the property of their respective holders.