javax.crypto

Mon Sep 25 21:39:00 GMT 2006

Marco Trudel wrote:
> Casey Marshall wrote:
>> 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
>> I tested further. Using Mohans initializer 
> (http://gcc.gnu.org/ml/java/2006-09/msg00052.html) on linux, I get the 
> providers mentioned above and it works.
> But using the same java code on mingw fails. I only get the default 
> provider, it doesn't matter if I use the initializer or not.
> I use a just compiled GCJ and the one for linux is slightly older. So I 
> guess it should work...
>> Any ideas? Workarounds?

Some additional informations: It works on cygwin! Is there a difference 
that can break it on mingw while it works on cygwin and linux?
Marco
PS: In return for working javax.crypto, cygwin seems to be broken when 
it comes to threads ;-)
>> Marco
>>>> 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.
>>>>>>