Cryptography provider

Tom Tromey tromey@redhat.com
Mon Nov 25 13:49:00 GMT 2002


>>>>> "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.

How is the last option different from using rhug?

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?

I think that is why BC isn't directly in rhug -- there is only build
infrastructure for it.

Anyway, we've used both BC and cryptix in the past.  I haven't tried
GNU crypto.

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.)

Tom



More information about the Java mailing list