javax.crypto

Casey Marshall csm@gnu.org
Wed Sep 20 20:21:00 GMT 2006


Marco Trudel wrote:
> Casey Marshall wrote:

>> However, even if the dynamic loading fails, we initialize our providers
>> with our default set. You can confirm that these providers are loaded by
>> calling Security.getProviders, and listing them.
> 
> Mohan already pointed out how to solve this for a static gcj (see his
> mail in the thread). In case you're still interested, here the providers:
> 
> Withhout Mohans static initializer:
> 
> gnu.java.security.provider.Gnu: name=GNU version=1.0
> 
> With:
> gnu.java.security.provider.Gnu: name=GNU version=1.0
> gnu.javax.crypto.jce.GnuCrypto: name=GNU-CRYPTO version=2.1
> gnu.javax.crypto.jce.GnuSasl: name=GNU-SASL version=2.1
> gnu.javax.net.ssl.provider.Jessie: name=Jessie version=1.0
> gnu.javax.security.auth.callback.GnuCallbacks: name=GNU-CALLBACKS
> version=2.1
> 

OK. It seems like this should still work without that initializer,
though. I do see that the Gnu provider does get loaded, which means that
the fallback mechanism isn't used. But if the GnuCrypto, et al.,
providers are referenced in the Security class, shouldn't they be linked
in? And, all those providers reference all their algorithms statically,
so they should all get pulled in.

That is, unless I'm misunderstanding how statically linking libgcj works.

> Actually I was only prototyping to check if things work at all. I had an old DES method somewhere and used it... I intend to use AES and updated my prototyp  :-)

OK, but it does look like Classpath/libgcj is missing some algorithms
(or possibly just aliases) that are supported by Sun.



More information about the Java mailing list