Cryptography provider

[Mark Wielaard]

Hi (added gnu-crypto-discuss to the CC),

[I must also apologize to Raif and Casey for not responding to their
email about this same topic a while ago]

On Mon, 2002-11-25 at 22:40, Tom Tromey wrote:
> >>>>> "Joerg" == Joerg Brunsmann <joerg_brunsmann@yahoo.de> writes:
> 
> Joerg> is there any consensus on how to make progress with java source
> Joerg> code for cryptography provider. There are several possibilities:
> 
> Joerg> - Import an existing provider like BC or cryptix.
> Joerg> - Use and enhance the classpath provider.
> Joerg> - Implement a new provider using gnu crypto. [1]
> Joerg> - Use rhug as a distributor for cryptography provider.
> Joerg> - Do nothing at all.
> 
> [...]
>
> Would there be legal problems with putting a crypto provider into
> Classpath or libgcj?  I mean, given that the projects are hosted in
> the US and worked on by US programmers?
> 
> [...]
>
> If there are no legal problems, then we're down to the usual sorts of
> packaging decisions; the kind of thing I've been avoiding looking at
> (hi Nic) a bit.  I can't avoid forever...
> 
> We aren't really limited to a single crypto provider.  If legal, we
> could pick one to ship, and ensure that the other ones can be easily
> integrated somehow.  (In fact the mechanism already exists in the form
> of the classpath.security and libgcj.security files.  Though there is
> a known problem here, things will still work ok.)

Raif Naffah and Casey Marshall have already solved this for the largest
part. GNU Crypto is distributed from the same place as GNUPG (gpg) is
distributed. And I think it is probably the smartest thing to let them
worry about the strange export restrictions that the US has. So GNU
Classpath/libgcj would make sure that the basic java.security framework
and the most basic algorithms (MD5/SHA/DSA) works and GNU Crypto would
provide the javax.crypto framework and the advanced algorithms.
GNU Crypto is very gcj friendly (see below).

Casey made sure that the Bouncy Castle JCE stuff (javax.crypto
interfaces) works correctly with gcj and the GNU Crypto provider (a bit
like the RHUG stuff, but now all sources and build system are in one
place.)
http://mail.gnu.org/pipermail/gnu-crypto-discuss/2002-November/000043.html

A very cool thing of GNU Crypto is that it comes with gcj optimized
implementions of some of the algorithms. And the GNU Crypto build system
produces a native gnu-crypto.so shared library that can be used directly
by gcj compiled programs. I am sure that Raif can tell a bit more about
the tweaks one has to do to get the most out of a java program that will
be interpreted by a traditional VM and one that will be compiled with
gcj. The GNU Crypto homepage has some benchmarks
http://www.gnu.org/software/gnu-crypto/

I thought that all java.security problems in Classpath/libgcj were fixed
now. What is the remaining known problem in this area?

Cheers,

Mark